Google's Go

grauzone none at example.net
Sat Jan 23 23:51:18 PST 2010


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.



More information about the Digitalmars-d mailing list