Foundation Classes - Inherited Standard_Failure from std::exception by dpasukhi · Pull Request #984 · Open-Cascade-SAS/OCCT

dpasukhi · 2026-01-06T15:04:25Z

First patch in iterative renovation of exceptions.

Updated exception classes to use std::shared_ptr instead of occ::handle
Removed redundant inclusion of <Standard_Type.hxx> in various header files across the project.
Removed Set methods for failure and its define template.
Removed Raise and Rerise static methods.
Deprecated getting message with old approach, and moving to what()

…Cascade-SAS#983) Replace Standard_*::Raise calls with throw statements for better exception handling

- Updated exception classes to use std::shared_ptr instead of occ::handle for memory management in Standard_OutOfMemory. - Removed redundant inclusion of <Standard_Type.hxx> in various header files across the project. - Enhanced error message handling in AIS_ViewController to utilize ExceptionType for better clarity. - Improved exception handling in SelectMgr_BVHThreadPool to provide more informative error messages. - General cleanup of header files to streamline dependencies and improve code maintainability.

…custom GetMessageString() - Updated multiple files to replace calls to GetMessageString() with what() for better standard compliance. - Improved exception message handling in BRepTest_CheckCommands, MeshTest_Debug, XDEDRAW_Props, XSDRAWIGES, OSD_ThreadPool, Standard_Failure, Standard_ErrorHandler, and others. - Enhanced memory safety and clarity in exception management across various modules.

…ward compatibility

… error message formatting

Copilot

Pull request overview

This PR implements the first phase of exception system modernization by making Standard_Failure inherit from std::exception instead of Standard_Transient, transitioning from OCCT's custom handle-based reference counting to standard C++ std::shared_ptr.

Key Changes:

Exception classes now use std::shared_ptr instead of occ::handle for memory management
Replaced deprecated GetMessageString() calls with standard what() method
Introduced ExceptionType() virtual method to replace runtime type information queries
Removed <Standard_Type.hxx> includes from exception header files (no longer needed without RTTI)

Reviewed changes

Copilot reviewed 166 out of 166 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
Standard_Failure.hxx/cxx	Core exception class redesign: inherits from std::exception, uses shared_ptr, implements what()
Standard_DefineException.hxx	Updated macro to generate exception classes without RTTI, using ExceptionType() method
Standard_ErrorHandler.hxx/cxx	Updated to use shared_ptr instead of handle for exception storage
Standard_OutOfMemory.hxx/cxx	Specialized implementation using shared_ptr singleton to avoid allocation during OOM
Exception header files (70+ files)	Removed Standard_Type.hxx includes, no longer needed without RTTI
Source files (50+ files)	Replaced GetMessageString() with what(), DynamicType()->Name() with ExceptionType()
OSD_signal.cxx	Updated signal handlers to use Jump() static method with shared_ptr
OSD_ThreadPool.hxx/cxx	Thread pool exception handling updated to use shared_ptr
Interface_CheckTool.cxx	Replaced RTTI-based type checks with dynamic_cast
migrate_raise_to_throw.py	Migration script for future Raise() to throw conversion

Copilot · 2026-01-06T15:05:21Z

-  Standard_EXPORT Standard_Failure& operator=(const Standard_Failure& f);
+  Standard_EXPORT Standard_Failure& operator=(const Standard_Failure& theOther);

  //! Destructor


The destructor override is missing documentation. Consider adding a brief comment explaining that it properly cleans up the reference-counted message and stack trace strings.

Suggested change

//! Destructor

//! Destructor override.

//! Releases internal, reference-counted message and stack trace strings.

Copilot · 2026-01-06T15:05:22Z

+    const char* theStackTrace);

-protected:
+private:


The myBuffer field should be documented to clarify that it's a fixed-size buffer to avoid dynamic allocation during out-of-memory conditions.

Suggested change

private:

private:

//! Fixed-size buffer storing the exception message to avoid dynamic allocation

//! during out-of-memory handling; the message is truncated to this size.

Copilot · 2026-01-06T15:05:22Z

-    int   aStackBufLen = std::max(aStackLength * 200, 2048);
-    char* aStackBuffer = (char*)alloca(aStackBufLen);
+    // Limit stack allocation to 64KB to prevent stack overflow
+    const int aStackBufLen = std::min(std::max(aStackLength * 200, 2048), 65536);


The magic numbers 200, 2048, and 65536 should be defined as named constants to improve code clarity and maintainability.

Copilot · 2026-01-06T15:05:22Z

  {
 #endif
-    theException.SetMessageString("System Signal received, check interrupt");
+


After removing the SetMessageString call, the exception is being re-thrown without any modification. Consider adding a comment explaining why the signal exception needs to be re-thrown versus handled differently.

Suggested change

// Re-throw low-level OSD exceptions (signals) so that they are handled by

// the global error/signal handling mechanism instead of being absorbed

// as a normal check failure.

…pagation

AtheneNoctuaPt · 2026-01-07T09:56:06Z

-    int   aStackBufLen = std::max(aStackLength * 200, 2048);
-    char* aStackBuffer = (char*)alloca(aStackBufLen);
+    // Limit stack allocation to 64KB to prevent stack overflow
+    const int aStackBufLen = std::min(std::max(aStackLength * 200, 2048), 65536);


std::clamp would probably be better here
const int aStackBufLen = std::clamp(aStackLength * 200, 2048, 65536);

AtheneNoctuaPt · 2026-01-07T10:08:46Z

 {
  // restrict length of the message by buffer size
-  size_t n = (theMessage ? std::min(strlen(theMessage), sizeof(myBuffer) - 1) : 0);
+  size_t n = (theMessage ? std::min(std::strlen(theMessage), sizeof(myBuffer) - 1) : 0);


Should be const and should be named properly.

AtheneNoctuaPt · 2026-01-07T10:13:22Z

  // first set line end symbol to be safe in case of concurrent call
  myBuffer[n] = '\0';


Header says that class is not thread safe, so maybe this comment is incorrect? In any case it is unclear how setting line ending symbol first would help in case of concurrent calls. If you understand what this comment tries to communicate, please update it.

My apologies, that all is artefacts of one of my tries (some algo which I removed during working on that patch) indeed need to clean up

…sage handling in Standard_OutOfMemory

dpasukhi added 5 commits January 6, 2026 14:30

Coding - Use throw instead of legacy Standard_Failure::Raise() (Open-…

e761651

…Cascade-SAS#983) Replace Standard_*::Raise calls with throw statements for better exception handling

Add deprecated GetMessageString() method to Standard_Failure for back…

9dd8143

…ward compatibility

Refactor exception handling to use std::exception::what() and improve…

5028ea5

… error message formatting

dpasukhi added this to the Release 8.0 milestone Jan 6, 2026

dpasukhi requested a review from Copilot January 6, 2026 15:04

dpasukhi self-assigned this Jan 6, 2026

github-project-automation bot added this to Maintenance Jan 6, 2026

github-project-automation bot moved this to Todo in Maintenance Jan 6, 2026

Copilot AI reviewed Jan 6, 2026

View reviewed changes

// formatting

d826f13

dpasukhi requested a review from AtheneNoctuaPt January 6, 2026 15:31

dpasukhi added 3 commits January 6, 2026 18:05

Refactor exception handling to use std::variant and improve error pro…

5a94dc9

…pagation

Refactor code formatting for improved readability and consistency

06ada85

// fix headers

062b858

AtheneNoctuaPt reviewed Jan 7, 2026

View reviewed changes

Refactor buffer length calculations to use std::clamp and improve mes…

2bb1419

…sage handling in Standard_OutOfMemory

AtheneNoctuaPt approved these changes Jan 7, 2026

View reviewed changes

github-project-automation bot moved this from Todo to Integration in Maintenance Jan 7, 2026

dpasukhi merged commit e1d3634 into Open-Cascade-SAS:IR Jan 7, 2026
18 checks passed

github-project-automation bot moved this from Integration to Done in Maintenance Jan 7, 2026

dpasukhi deleted the std_excpetion branch January 7, 2026 12:22

VM4Dim mentioned this pull request Feb 28, 2026

Part: Use signal handlers based on OCC's implementation FreeCAD/FreeCAD#27854

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Foundation Classes - Inherited Standard_Failure from std::exception#984

Foundation Classes - Inherited Standard_Failure from std::exception#984
dpasukhi merged 10 commits intoOpen-Cascade-SAS:IRfrom
dpasukhi:std_excpetion

dpasukhi commented Jan 6, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 6, 2026

Uh oh!

Copilot AI Jan 6, 2026

Uh oh!

Copilot AI Jan 6, 2026

Uh oh!

Copilot AI Jan 6, 2026

Uh oh!

AtheneNoctuaPt Jan 7, 2026

Uh oh!

AtheneNoctuaPt Jan 7, 2026

Uh oh!

AtheneNoctuaPt Jan 7, 2026

Uh oh!

dpasukhi Jan 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	//! Destructor
	//! Destructor override.
	//! Releases internal, reference-counted message and stack trace strings.

+    // Re-throw low-level OSD exceptions (signals) so that they are handled by
+    // the global error/signal handling mechanism instead of being absorbed
+    // as a normal check failure.

		// first set line end symbol to be safe in case of concurrent call
		myBuffer[n] = '\0';

Conversation

dpasukhi commented Jan 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

AtheneNoctuaPt Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

AtheneNoctuaPt Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

AtheneNoctuaPt Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

dpasukhi Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants