On 9/28/2014 1:56 PM, H. S. Teoh via Digitalmars-d wrote:
It looks even more awful when the person who wrote the library code is
Russian, and the user speaks English, and when an uncaught exception
terminates the program, you get a completely incomprehensible message in
a language you don't know. Not much different from a line number and
filename that has no meaning for a user.
I cannot buy into the logic that since Russian error messages are
incomprehensible to me, that therefore incomprehensible messages are ok.
That's why I said, an uncaught exception is a BUG.
It's a valid opinion, but is not the way D is designed to work.
The only place where
user-readable messages can be output is in a catch block where you
actually have the chance to localize the error string. But if no catch
block catches it, then by definition it's a bug, and you might as while
print some useful info with it that your users can send back to you,
rather than unhelpful bug reports of the form "the program crashed with
error message 'internal error'".
If anyone is writing code that throws an Exception with "internal error", then
they are MISUSING exceptions to throw on logic bugs. I've been arguing this all
along.
if the program failed to catch an exception, you're already screwed
anyway
This is simply not true. One can write utilities with no caught exceptions at
all, and yet have the program emit user friendly messages about "disk full" and
stuff like that.
so why not provide more info rather than less?
Because having an internal stack dump presented to the app user for when he,
say, puts in invalid command line arguments, is quite inappropriate.
Unless, of course, you're suggesting that we put this around every
main() function:
void main() {
try {
...
} catch(Exception e) {
assert(0, "Unhandled exception: I screwed up");
}
}
I'm not suggesting that Exceptions are to be thrown on programmer screwups - I
suggest the OPPOSITE.
