[phobos] Calling abort() on unhandled exception

[Michel Fortin]

Le 2010-07-30 à 1:01, Andrei Alexandrescu a écrit :

> Exception messages are meant to be seen by users.

I disagree.

The error message of an exception might be meaningful in a small program that does only one thing at a time, but in general to give the user an understandable error message you need more context information.

For instance, say you have a command line program that takes as input a HTTP URL and downloads a web page with all its related content. Outputting an error such as "Socket could not connect to host 1.2.3.4 on port 80: timeout" is quite cryptic because you don't even know which sub-resource it was trying to fetch, nor why it fetched that resource (it might be that the HTML parser didn't get the domain name correctly). And anyway it's probably a bug because it should just have skipped that resource and went on. If you want to debug that you need a stack trace to know which resource handler should have caught that exception, and you might want to attach the debugger to stop when the uncaught exception is thrown and inspect the circumstances.

And you probably don't want to handle localization inside the exception handling mechanism either.

Also, for GUI programs an uncaught exception is always a bug because it'll make the application suddenly quit with no message visible to the user. Exiting a GUI application with abort() on OSX will ensure that the OS shows an error message about the application having crashed, and for GUI applications OSX will save a quite helpful crash report the user can then send to the developer. You don't want uncaught exceptions to silently quit the application and just be logged to the system console with no stack trace.

So I believe in the vast majority of cases calling abort() and showing a stack trace is what you want. That's what most other languages do. It's easy to get what Andrei wants with a "try {...} catch (Exception e) { writeln(e); exit(-1); }" in the main, but I'd generally recommend against this.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/