Exception handling

[douardda]

Its simple, it works perfectly on other platforms.

No it's not that simple. I've seen buggy code working properly on some platforms due to lucky side effects... the code was buggy nonetheless. Answering this with "It works for me"... well

I think your whole development platform is faulty.

Are you telling me that we should forget about Ubuntu LTS and Debian users?

Again, your environment has a problem. So first get your debugger running before you blame the application code!

My environment is fine, it's that static-only QtUiTools lib that obfuscates everything...

David

[shoogen]

we need a dedicated FreeCAD C++ exception class exported in Python (say FreeCASError) so we can replace those "except:" statements by "except FreeCADError:" ones?

We could avoid catching all exception even using an existing one, like "RuntimeException". But to be useful, we should highly use inheritance to structure 'our' exceptions.

[logari81]

I think your whole development platform is faulty.

hehehe, I suppose you are joking. No developper in the world would dare such a strong statement for any of the major operating systems (MS Windows, Linux, OS X, BSDs) and compilers (msvc,gcc,llvm,..). I don't like windows and msvc but I would never state that the software I write doesn't need to work on windows because it is a flawed platform.

[jriegel]

Ok then, exceptions not passing c-code? faulty...
A static lib when you for sure need a dynamic lib? faulty...
Whether its a packaging error or python compiled with the wrong compiler flags - I don't care. We need a C++ programming environment with a certain level. Exceptions was introduced to C++ in the early 90s. Should be working by now...

Sure, we can catch each and every C++ exception everywhere and do what? Raise a python exception which raise a C++ one again? If you look at the call stack we go really often in and out of python. The whole point of an exception is that it goes transparent through the call stack and gets handled where it makes sense and not everywhere. If not we can go to the good old days of return value error handling, when programming was simple.

To be honest, I can still not belief the Linux programming model has such a grave limitation/bug.

[douardda]

Ok then, exceptions not passing c-code? faulty...

I don't get it. How can a C++ exception pass C-code reliably? (I mean C code, not C with non standard proprietary extensions, not C compiled with a C++ compiler).

I know, MS added support for this by the mean of their "structured exception handling" mecanism (provided you use /EH compiler option I believe)... which is a false good idea.

gcc also provides the "-fexception" flag to ease debugging when mixig C with C++, but it cannot be considered as a safe way to make C++ exception "pass" through C code. According to gcc documentation "[-fexception] will make debugging a C language function called as part of C++-induced stack unwinding possible."

C is not designed for exception handling. It's not exception-safe and it will never be. How can you ensure there is no resource leak in C code in the middle of a C++ call stack? Unless I miss something about what C is, It cannot be reliable.

I think C++11 added support for this situation, but we are not talking about C++11 here.

I might be wrong, I don't know exactly how/if MS can provide a "safe" way of passing C++ trhough C code (unless C is compiled using the C++ compiler on C code declared as extern "C" or like).

A static lib when you for sure need a dynamic lib? faulty...

Agreed, and it has been reported for years on Qt bugtracker.
It's a pity it"s not been fixed, but this is the situation. So now, how do we get around this problem?

Whether its a packaging error or python compiled with the wrong compiler flags - I don't care. We need a C++ programming environment with a certain level. Exceptions was introduced to C++ in the early 90s. Should be working by now...

Which we do not have, since CPython is pure C code, not C++, not C-with-fancy-additions.

Sure, we can catch each and every C++ exception everywhere and do what? Raise a python exception which raise a C++ one again? If you look at the call stack we go really often in and out of python. The whole point of an exception is that it goes transparent through the call stack and gets handled where it makes sense and not everywhere. If not we can go to the good old days of return value error handling, when programming was simple.

I agree with you, C++ is just an over-complex aberration

To be honest, I can still not belief the Linux programming model has such a grave limitation/bug.

These are not limitations. These are juste respected norms, standards and interoperability concerns. The kind of things MS never bother to deal with, I fully agree with you on that point.

So, now, have you (or anyone else around) some helpful clues or advices to ease fix this problem?
At first, I just wanted to help a bit FreeCAD by writing Python code, not fight with C++ exceptions not passing C, nor with any FreeCAD developper. But if the only answer is "I don't care" or "GNU/Linux stinks", well, I won't insist too much... And believe me, I know a bit how to write Python code, which might be useful for FreeCAD...

David

[triplus]

I have been fighting Windows bugs for most of December, and wow, I've seen the dark side of Windows development with regards to working outside Microsoft's preferred tool set.

http://www.openshotvideo.com/2014/01/ep ... -of-3.html

Of course, Mac and Linux support has been super easy, and simply a pleasure to work in those development environment.

It all comes down to perspective.

[logari81]

I have been fighting Windows bugs for most of December, and wow, I've seen the dark side of Windows development with regards to working outside Microsoft's preferred tool set.

sorry triplus, this is a different case, Thomas from OpenShot refers to developping in Windows with MinGW, not with VS. Jürgen uses VS, the Microsoft's preferred tool, which is one of the most efficient tools for developping software but it is closed source.

I think what is necessary here is a minimal working example to demonstrate the speculated difference between msvc and gcc and make sure that everybody in this discussion talks about the same thing.

[jriegel]

I don't get it. How can a C++ exception pass C-code reliably? (I mean C code, not C with non standard proprietary extensions, not C compiled with a C++ compiler).

Thats quit simple, compile python with a C++ compiler and enable stack unwinding (like it is on M$)! We have 99% C++ libs, and Exceptions are the ONLY acceptable way of error handling in a big application like FreeCAD! What is unacceptable is the runtime crashes on that cases. No wonder FreeCAD crashes so much on Linux and Mac if our error handling concept is voided by one wrong compiled lib.

About Stack unwinding on C-Libs;
Your basically right, you loose the dynamically allocated memory along the unwinded stack (in c-libs), but in case of python its not so bad. Its a recursive interpreter and hold there fore its state on the stack, which get freed on unwinde.

@Werner
Catching and rethrowing is a problematic choice, cause you have to transfer all kind of exception information in and out of python. You create tons of code for every exception type of every library at every transfer point into python, cause you never know in advance how the call stack looks like! Especally when the user do its own scripts. So a OCC exception can pass through the Mesh code. You can not handle this in a gracefull way, you have to let it pass through a point where you can handle it....

C++ Exception handling is one of the big breakthrough in programing and handling error states in big applications! It is one of the killer concepts present in ALL programing languages since then. Its absolutely VITAL to have it working on a platform FreeCAD should run!!!

All this was decided in the early design phase of FreeCAD (2001/2002) where I do extensive research on that matters. Like loading C++ code with the python module loader and passing in and out of the python interpreter on multiple levels, and many more. Exception handling was a no brainer! There is NO other viable concept!

So my conclusion is:
Bug report for debian. python.so have to support C++ Exceptions or they have to package another version (python-c++.so) which do. There is no other way if you want embed python in a (big) C++ app.

So still, both are problems of the dev-environment Clean it up, or you will have a LOT of crashes in FreeCAD!

[shoogen]

How about splitting the topic?
Maybe merging it with mine about exception handling?
I don't get the whole concept. As fas as i understand we have to decide in every implementation of a python function in c++, what to so about exceptions. Either we convert them to a python exception (Werners approach) or we pass it through the call stack (Jürgens approach).
But what is the use case for an exception that is not visible for python code?
EDIT: On windows I've seen SIGSEGV shown in the report window. Often FreeCAD crashes just a few seconds later then.

[wmayer]

Thats quit simple, compile python with a C++ compiler and enable stack unwinding (like it is on M$)! We have 99% C++ libs, and Exceptions are the ONLY acceptable way of error handling in a big application like FreeCAD! What is unacceptable is the runtime crashes on that cases. No wonder FreeCAD crashes so much on Linux and Mac if our error handling concept is voided by one wrong compiled lib.

In the first place this has something to do with bugs in the (C++) libraries. In OCC there are still many bugs which cause segmentation faults. Therefore OCC provides a static function OSD::SetSignal to handle somehow this kind of errors. For Windows/VC++ it internally uses the "structured exception handling" mechanism and for Linux systems (I don't know about Mac OS X or all the different UNIX systems) it uses a different concept which appeared to work in most cases but not in all.
So, this highly depends on the platform and has nothing to do with the specification of the C/C++ languages. And also it's a myth to believe that with a simple "catch(...)" you could handle all kind of errors -- such as the mentioned segmentation faults. This is simply not true!

About Stack unwinding on C-Libs; Your basically right, you loose the dynamically allocated memory along the unwinded stack (in c-libs), but in case of python its not so bad. Its a recursive interpreter and hold there fore its state on the stack, which get freed on unwinde.

I'm sure that if Python allowed to forward C++ exceptions it would totally mess up the internals and at least would lead to massive memory leaks or more serious problems. E.g. when it increments the reference counter of an object, calls a function that calls a C++ extension that throws an exception the reference counter will never be decremented. So, from this point of view it's a rather a bad thing that the VC++ silently forwards exceptions to the calling instance in C++.

@Werner
Catching and rethrowing is a problematic choice, cause you have to transfer all kind of exception information in and out of python. You create tons of code for every exception type of every library at every transfer point into python, cause you never know in advance how the call stack looks like! Especally when the user do its own scripts. So a OCC exception can pass through the Mesh code. You can not handle this in a gracefull way, you have to let it pass through a point where you can handle it....

It can never ever be a proper solution to throw a C++ exception (e.g. OCC's Standard_Failure) through Python and handle it in the FreeCAD core system. There is no other (proper) way than setting the Python error flag from within the extension module and then handle the Python error flag in the core system. And besides this you cannot compare C++ exception with Python exceptions because technically they work completely differently.

To be honest, I can still not belief the Linux programming model has such a grave limitation/bug.

To a proper exception handling it also belongs to release memory (see reference counter) and this isn't possible by forwarding C++ exceptions through Python. So why do you insist on a "solution" that leads to massive memory leaks and maybe even more serious problems?

And also this whole discussion about "handling C++ exceptions in C" is of theoretical nature only. In practice I had this issue only once after more than ten years of development on FreeCAD. It took me only a few hours to find this out (because before I didn't know this either) and deal with it.