BRepFilletAPI_MakeChamfer errors cannot be trapped with try/catch

Marco Balen
Wed, 09/17/2014 - 22:31

Forums:

Hi,

How can I trap an error in BRepFilletAPI_MakeChamfer ?
In some situation I get an application crash when I "build" the chamfer.
I cannot trap the error with Try/catch and the "IsDone()" is not reached to check the error.
Any suggestion ?

My code :

TheShape : the shape build with BRepPrimAPI_MakePrism() from "Face"
Face : the extrusion face of "TheShape" (TopoDS::Face(PrismMaker.FirstShape()))

.....

try {
BRepFilletAPI_MakeChamfer mkChamfer(TheShape);
TopExp_Explorer aEdgeExplorer(Face , TopAbs_EDGE);
while(aEdgeExplorer.More()){
TopoDS_Edge aEdge = TopoDS::Edge(aEdgeExplorer.Current());
//Add edge to fillet algorithm
mkChamfer.Add(Chamfer , aEdge, Face);
aEdgeExplorer.Next();
}

mkChamfer.Build();
if (mkChamfer.IsDone())
TheShape = mkChamfer.Shape();

}catch(...){
never reached
}

Timur
Fri, 09/19/2014 - 15:21

Hi, same situation here.

I am using BRepOffsetAPI_MakeOffset to build offset for a certain wire. The call to Perform() leads to a crash that cannot be trapped with try/catch. What I think is happening is that an exception is thrown during stack unfolding after throwing a Construction Error, which violates C++ coding standard.

P G
Fri, 09/19/2014 - 16:35

Hello
Could u share the BREP file of the input 'wire' and offset value.
regards
PG

Timur
Fri, 09/19/2014 - 19:31

Hi, thanks for quick reply!

I've attached the Brep file.

Offset value is -1.39018

Note that I am using OpenCASCADE 6.6

Attachments:

BrepFile.txt

P G
Mon, 09/22/2014 - 09:44

it does not crash in 6.7.1 Test harness on windows,
'b' is the face from the brep file.

Draw[14]> mkoffset r b 1 -1.39018
An exception was caught in BRepFill_OffsetWire::Perform : 005C3A2C : Standard_Failure: BRepFill_OffsetWire::FixHoles(): Wrong wire.
Error: Offset is not done.

Timur
Fri, 09/26/2014 - 13:33

Hi,

I've checked the newer OpenCASCADE 6.7.1, and it does not crash.
The offset building fails, and I see an exception message in stderr, but then everything continues to function normally, isDone() returns false, and no exceptions are caught (because none are thrown apparently).

Marco Balen
Fri, 09/19/2014 - 20:37

Hi PG,
I have attached the shape that I have to chamfer.
The chamfer value is 1.4 millimeters.
The reference face is one of the two plane faces.

Thanks for your help

Attachments:

test_0.brep

Forum supervisor
Mon, 09/22/2014 - 20:21

Dear Marco,

In order for the application to be able to catch system signals (access violation, division by zero, etc.) in the same way as other exceptions, the appropriate signal handler shall be installed in the runtime by the method OSD::SetSignal().

Normally this method is called in the beginning of the main() function. It installs a handler that will convert system signals into OCCT exceptions.

In order to actually convert signals to exceptions, macro OCC_CATCH_SIGNALS needs to be inserted in the source code. The typical place where this macro is put is beginning of the try{} block which catches such exceptions.
See for details "Open CASCADE Technology / Users Guides/ Foundation classes /Handling an Exception" chapter.
I do hope it will help you.
Best regards
FSR

Marco Balen
Thu, 09/25/2014 - 22:20

Hi,

Excuse me for the delay , I was out of office in these days.

I have done some adjustment in my code. There was no material to do the chamfer. And than I get a better behaviour.
I have tried to insert the OCC_CATCH_SIGNALS macro between the try/catch statements and I have inserted the OSD::SetSignal() in my application main(), but I cannot trap some "division by zero" error.
With SetSignal() I get an "division by zero" in chamfer.Build() function, which I cannot trap.
Without SetSignal() I not receive any exception from the Build() method and I can test correctly the IsDone() method (no operation done).
My code is :
try {

OCC_CATCH_SIGNALS
...
mkChamfer.Build();
if (mkChamfer.IsDone())
TheShape = mkChamfer.Shape();
...
}catch(Standard_DivideByZero)/*...*/{//catch(Standard_Failure){

has you can see I have tried with Standard_DivideByZero,...,Standard_Failure and also Standard_NumericError.

I seems that in some situation the method raise an error which I cannot trap

The application is build with VisualStudio 10.00 and OCC6.6.

The documentation tells me :
On Windows and DEC, these macros are not defined by default, and normal C++ exceptions are used in all cases, including throwing from signal handler. Thus the behavior is as expected in C++.

Any suggestion ?