Steve Schveighoffer wrote:
Um, no. Exceptions can easily be uncaught (oops, forgot a try catch!). I don't
want the end result of an uncaught exception to be a bug that's impossible or
difficult to determine because no stack trace was printed. Let's consider that
an exception may not be easily repeated and is most likely encountered by a
user, not a developer. Giving a mechanism to communicate the problem as
completely as possible from the user developer should be the default.
We should classify any exception or error that gets thrown outside of main to be
an exception that was not planned for by the developer, and therefore a program
error. This should trigger as much info as possible, definitely including a
stack trace, and possibly a core dump (though, dumping core after catching an
exception is next to useless).
If you want to avoid printing stack traces, catch the exception inside of main.
I don't think it's too much to ask.
That argument goes both ways, i.e. I could tell you it's not much to ask
to insert a try/catch if you care about the stack trace.
It comes back to doing a sensible thing by default. main() without a
try/catch is common in short scripts. I am currently _exceedingly_ happy
that I'm able to write 10-line scripts that do something interesting and
behave reasonably in all circumstances. Obviously, a stack trace is not
something anyone would be interested in for a short script. You are
saying that I should take a size hit in order to protect you from adding
6 lines to a 100,000 lines program.
D should be script-friendly, it's a huge boon and a huge appeal, and
stack traces don't go with script friendliness. Serious programs can
afford the slight overhead.
See my point?
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
