Exceptions cause program to abort and never print their error messages
yurivict opened this issue · 7 comments
For example, main.cpp:132: throw std::runtime_error("Unable to open xyz input file!\n");
There should be a try...catch block at the top of main and possibly at the entry points of all threads.
Why do you think exceptions are even in the C++ language? 🤣
There is no bug in ERKALE. If the user fucks up, the error message is printed out, e.g. in your exact example
terminate called after throwing an instance of 'std::runtime_error'
what(): Unable to open xyz input file!
If this does not happen in FreeBSD, you should file a bug against the C++ runtime library package.
The handling that you see is discretionary, up to the starter module that calls main. It is not required by any standard, and is implemented on linux as a convenience.
Systems that don't have such optional extra-functionality would just print "Abort" and not show the message.
C++ programs are expected to process exceptions in order to get such printout in a predictable way.
Why do you think exceptions are even in the C++ language? rofl
Exceptions are supported by C++, as well as by other languages.
This has nothing to do with this problem.
The handling that you see is discretionary, up to the starter module that calls main. It is not required by any standard, and is implemented on linux as a convenience.
Again, the problem is not in ERKALE, but in
- the user who does not use the code in the proper way and
- in user non-friendly environments.
Systems that don't have such optional extra-functionality would just print "Abort" and not show the message.
C++ programs are expected to process exceptions in order to get such printout in a predictable way.
Exceptions are processed properly in the code in places where it makes sense to process them.
It makes absolutely no sense to wrap the code in catch statements, because it would take a lot of time and I doubt anyone would even see the changes. 100% of high performance computing happens on Linux architectures, and that's what I am targetting.
The code does work on other architectures as well. I am not to blame for user error.
Your program terminates when the exception unwinder reaches the function above main, the area not covered by the exception mechanism, after not having been able to find the exception handler for the thrown data type. Generally, exceptions can be thrown from different languages, and have no general root type. Even in C++ alone there can be no generic exception handler. For example, this is a valid code:
class C {
/// ...implementation...
};
void f() {
throw new C;
}
This exception can only be caught by a class-specific exception handler. One can also throw a primitive type, or a pointer, and this is also a valid behavior. Such exception can only be caught in an application-specific way.
What you expect the framework to do is to guess the language, to have knowledge about C++, to have knowledge about STL, to guess that this might be an STL-derived exception or perhaps a std::string derived exception, or perhaps just a static string, and to print the message accordingly. This is too much to expect from the system to cover for you failing to catch your exceptions.
Additionally, the C++17 standard draft says
18.3 (note 9) If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined.
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf)
So, according to the C++ standard, you rely on an implementation-defined behavior. This behavior can't even be properly defined in the context of diverse, multi-language apps, or just C++ apps with diverse exception architecture, see above.
In simple terms, this is a flaw in your program, not in the system.
Do you have a simple suggestion on how to modify the program to suit your wants?
I have quite a few irons in the fire, and cleaning up old code that works isn't very high on my list of priorities...