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.