dsimcha wrote:
Multiple return values are a horrible substitute for exceptions, because they
require the programmer to explicitly check the return value. (When's the last
time you checked the return value of printf, or even malloc?) IMHO the best
thing
about exceptions is that they provide a sane default for error handling: If you
don't handle them then you've effectively asserted that they can't happen in
your
situation. If this "assertion" fails, then our program fails fast and with an
error message that massively narrows down where the problem is. I flat-out
refuse
to program in a language where the default is for errors to be ignored and I
have
to constantly write explicit error-checking boilerplate even if I don't care
about
handling the error.
Exception handling in D (or C++/Java for that matter) isn't that great
either. In D, you don't even know what exceptions a function may throw.
It's completely dynamic. You may even accidentally catch unknown
exceptions, because your catch-filter isn't "narrow" enough.
Java has checked exceptions, but they are misdesigned, get in the
programmers way, and generally suck. Feels almost like D copied the
standard Java feature by the letter, removing checked exceptions, and
call that an improvement.
Also, let's have a look how exceptions improve the robustness of most
Java code:
try { something(); } catch (Exception e) { Logger.getLogger().log(e); }
I guess D programmers are just better than D programmers, which makes
this example out of place, of course. Or they just let it fall through,
until it gets catched by a similar catch-all statement.
Generally, exceptions as they are implemented in some popular languages
seem to give the impression that you don't need to care about error
handling. That isn't always true and probably only works in small
command line tools.
