Hacker News Reader

Comment by uriel | Hacker News Reader

> The idea of exceptions is not primarily reading out details from the throw exception object, but to let programmers code the "happy flow" as if errors can not happen.

The problem is that errors can and will happen, and exceptions make the control flow of error handle unpredictably convoluted.

From a control flow point of view exceptions are worse than COMEFROM.

> It also makes it easier to let callers further up in the call-chain to set the policy of of what to do in case of an error.

Callers that do not have any of the real context in which the error happened, and that often can't do anything particularly smart about it other than throw their hands in the air.

View on HN

Thanks for mentioning

http://en.wikipedia.org/wiki/COMEFROM

A joke in 1973 -- kind of a reality with the exceptions. As early as FORTRAN IV, IO operations errors were handled in higher level programming languages:

  WRITE( 6, 30, ERR=390 )

specified that error handling for that given write operation was behind the label 390.

The march of progress, just like even the first FORTRAN circa 1956 did

     WRITE (6, 150) X
 150 FORMAT (F10.2)

But C++ since 1988 improved it with

  cout << setw(10) << setprecision(2) << showpoint << x;

or Java 1996 with:

    java.text.NumberFormat formatter = 
         java.text.NumberFormat.getNumberInstance(); 
    formatter.setMinimumFractionDigits(2); 
    formatter.setMaximumFractionDigits(2); 
    String s = formatter.format(x); 
    for (int i = s.length(); i < 10; i++) 
         System.out.print(' '); 
    System.out.print(s);

The march of progress.

> The problem is that errors can and will happen, and exceptions make the control flow of error handle unpredictably convoluted.

I take it you never have seen the "leaning Eiffel tower of nested if's in C/Pro-C? As I wrote, in a language with exception handling you code as if errors never would happen. And then you put using/try+finally/block-exit clauses around your statements to assure cleanup will happen no matter what.

How is that convoluted? Good such code looks almost naïve to me.

>Callers that do not have any of the real context in which the error happened, and that often can't do anything particularly smart about it other than throw their hands in the air.

Well, exactly how smart a caller can be is decided by the protocol between caller and callee. It's no different than what return-values would have given you IMHO.

Reply on news.ycombinator.com