5 ms·
The entire concept of an unending exception chain seems flawed to me, and having to carefully annotate or check everywhere is still error-prone for programmers.
by makecheck 10y ago
The entire concept of an unending exception chain seems flawed to me, and having to carefully annotate or check everywhere is still error-prone for programmers.
It ought to be possible to create impenetrable exception boundaries, such as:
- A compilation unit / file.
- Something identified as a “library” (perhaps based on namespace).
- The program itself.
If I want my “library” to automatically trap all exceptions that I throw, I should be able to. I shouldn’t have to worry that entire programs may crash because of mistakes from exceptions. Similarly, a programmer should be able to say, ONCE (regardless of any functions added in the future), “trap all exceptions from code in this file using this function” and be done with it.
And, if the language had been designed with this kind of visibility into exceptions, one would also have more useful information at the time they are trapped. For instance, obviously exceptions propagating all the way to main() have very little useful context but knowing that an exception is trapped in a file scope would be huge for debugging.
- jstimpfle 10y agoEntire programs can crash from a bad library, whether there are exceptions or not. If you need more isolation, maybe you can make a design based on restartable servers.
- youdounderstand 10y agoThere are real use cases where you need granular control, like implementing WinRT components on Windows. Basically, anytime you need to have a barrier between error code-based and exception-based code, or at ABI boundaries.
- pjc50 10y agoAnd this is why the people who wrote this code base I'm maintaining have manual stack-tracing code for the application - so whenever an exception is constructed of certain types we can dump its call location into the logs. Otherwise exceptions just appear as weird nonlocal flow control that loses information. GCC users have backtrace_symbols() for this. (It was an interesting exercise to see how much of the ARM stack unwinding I could do in C++ rather than assembler; I managed it with only one asm instruction to get the link register and a lot of instruction-decoding C++)
- wvenable 10y ago> I shouldn’t have to worry that entire programs may crash because of mistakes from exceptions. Why? This is the best possible outcome. Continuing to run is the worst possible outcome from a correctness, security, and stability perspective. I can't imagine more of an anti-feature.
- makecheck 10y agoSimple: the meaning of the exception is known only to the guts of your library, and it is being automatically promoted to “catastrophic failure” when it could actually be a very trivial problem or at least something that you could recover from gracefully. Instead, because you potentially forgot an exception clause somewhere, my entire program dies in an unpredictable place? That makes the entire model ridiculous.
- wvenable 10y agoAlmost all exceptions cannot be recovered from gracefully. Those that can, are generally recovered/retried from within your own code not the libraries code. An unhandled exception should always be a catastrophic error -- exceptions are exactly for situations where the code is in an unexpected situation. If you keep running, the application is now running in that unpredictable state. You just want to bury your head in the sand at a library boundary but I don't see why that's desirable. A well designed program (that isn't written in Java) should only have a handful of catch statements.
- makecheck 10y agoYou are making huge assumptions about how people use exceptions, and huge assumptions about the goals of a program. While you and I may agree that exceptions should be used for unexpected situations, nothing forces people to use them that way. A library programmer may have weird ideas about what warrants an exception. If my application appears to be functioning correctly, I should not have to risk crashing because of something that cannot be proven to affect my program in a significant way. My program may be trying to remain stable (e.g. a GUI for a user), and the user may well not care if my program has encountered an issue if it means throwing out their last 10 minutes of unsaved work. Some programs like CAD tools may run for days, and even partial results with logged errors can still be important to preserve in lieu of stupid crashes.
- paulddraper 10y ago> I shouldn’t have to worry that entire programs may crash because of mistakes from exceptions. Uh huh. And how do you feel about sefaults?