3 ms·
Exceptions reflect the realization that the proper place to handle an error is generally not where the error itself occurs. The problem with exceptions (and err
by thequux 4y ago
Exceptions reflect the realization that the proper place to handle an error is generally not where the error itself occurs. The problem with exceptions (and error returns, for that matter) is that the best place to handle an error is also not the same as the best place to decide how to handle the error.
So far, the only programming environment I've seen that makes a three-way distinction between raising, recovering, and deciding how to recover from an error is Common Lisp with its condition system[1]. However, I've successfully implemented the idea in Java using exceptions as the non-local control flow primitive, and in C using setjmp/longjmp.
[1]: https://lispcookbook.github.io/cl-cookbook/error_handling.html https://lispcookbook.github.io/cl-cookbook/error_handling.ht...
- XorNot 4y ago> the best place to handle an error is also not the same as the best place to decide how to handle the error. I'm not sure I follow the distinction here, or at least why it would be important? i.e. if I parse "decide how to handle the error" as catching the exception, where I handle it is surely basically anywhere since I'm not restricted in calling into other code to do so.
- lmz 4y agoCommon Lisp exceptions are resumable which is the main difference between it and more common languages like Java and C++. e.g. "Decide" can also include deciding to retry the operation with different inputs.