3 ms·

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 h

by Flow 15y ago

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. 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.

masklinn 15y ago
And then, if you go one step further to conditions (Smalltalk, Common Lisp) callers can even setup a recovery policy for the error without unwinding the stack. Smalltalk systems use this to great success to allow for e.g. dropping straight into the debugger at an error point (without any loss of context) even when the system is not technically being debugged.
- Flow 15y ago
  I had Common Lisp Conditions in mind when I wrote my message above. Have an upvote for knowing stuff. :)
uriel 15y ago
> 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.
- Flow 15y ago
  > 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.
- acqq 15y ago
  Thanks for mentioning http://en.wikipedia.org/wiki/COMEFROM 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.

by Flow 15y ago

masklinn 15y ago

And then, if you go one step further to conditions (Smalltalk, Common Lisp) callers can even setup a recovery policy for the error without unwinding the stack. Smalltalk systems use this to great success to allow for e.g. dropping straight into the debugger at an error point (without any loss of context) even when the system is not technically being debugged.

Flow 15y ago
I had Common Lisp Conditions in mind when I wrote my message above. Have an upvote for knowing stuff. :)

uriel 15y ago

> 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.

Flow 15y ago
> 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.
acqq 15y ago
Thanks for mentioning http://en.wikipedia.org/wiki/COMEFROM 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.