debugMinor
Is there a theory of exception hierarchies?
Viewed 0 times
theorythereexceptionhierarchies
Problem
I'm familiar with a dozen of programming languages which have exceptions in some way, yet I came to witness two "pathological" tendencies.
-
There doesn't seem to be a common pattern or hierarchy of exceptions. Every language basically rolls its own version, and if the exceptions make it into the standard, then the kinds of exceptions that one finds in the standard would be rather arbitrary (mostly those which were implemented while creating language tools, such as reading source code from string or an exception to invoke debugger, or the one which happens when the file cannot be found etc.)
-
Exceptions defined by the language are very rarely reused by user programs. There would be usually one or two popular exceptions ("not implement" for example). Though most times programmers will create their own exceptions. (Compare this to, for example, creating new numeric types or new collection types).
This looks like a terrible omission to me. How comes no one knows what kinds of errors will be needed in user programs? I was hoping for there to be a kind of nice hierarchy, similar to numeric types, collections, object system etc.
Worse yet, Goolge and Wikipedia provide very little help on the subject. So far I've only found a paper on functional exception which opens in a passage:
This paper argues that lazy functional programming not only makes
built-in exception handling mechanism unnecessary, but provides a
powerful tool for developing and transforming programs that use
exceptions
(A Functional Theory of Exceptions, Mike Spivey, 1988)
But I think that exceptions are good. I don't want to transform programs that use exceptions, on the contrary, I want to make the use of exceptions less chaotic.
The question:
Is there a theory of exceptions? If so, what is it called? What are, if any, the cornerstone works outlining the basis of it?
-
There doesn't seem to be a common pattern or hierarchy of exceptions. Every language basically rolls its own version, and if the exceptions make it into the standard, then the kinds of exceptions that one finds in the standard would be rather arbitrary (mostly those which were implemented while creating language tools, such as reading source code from string or an exception to invoke debugger, or the one which happens when the file cannot be found etc.)
-
Exceptions defined by the language are very rarely reused by user programs. There would be usually one or two popular exceptions ("not implement" for example). Though most times programmers will create their own exceptions. (Compare this to, for example, creating new numeric types or new collection types).
This looks like a terrible omission to me. How comes no one knows what kinds of errors will be needed in user programs? I was hoping for there to be a kind of nice hierarchy, similar to numeric types, collections, object system etc.
Worse yet, Goolge and Wikipedia provide very little help on the subject. So far I've only found a paper on functional exception which opens in a passage:
This paper argues that lazy functional programming not only makes
built-in exception handling mechanism unnecessary, but provides a
powerful tool for developing and transforming programs that use
exceptions
(A Functional Theory of Exceptions, Mike Spivey, 1988)
But I think that exceptions are good. I don't want to transform programs that use exceptions, on the contrary, I want to make the use of exceptions less chaotic.
The question:
Is there a theory of exceptions? If so, what is it called? What are, if any, the cornerstone works outlining the basis of it?
Solution
There's a large number of publications on exceptions, with quite a few theoretical investigations. Here is an unstructured and far from complete list with some examples. Sorry, I don't have
time at the moment for a more focussed reply.
time at the moment for a more focussed reply.
- B. Randell, System Structure for Software Fault Tolerance.
- J. B. Goodenough. Exception handling: Issues and a proposed notation.
- J. B. Goodenough. Structured exception handling.
- B. G. Ryder, M. L. Soffa, Influences on the Design of Exception Handling.
- D. Teller, A. Spiwack, T. Varoquaux, Catch me if you can: Towards type-safe, hierarchical, lightweight, polymorphic and efficient error management in OCaml.
- X. Leroy, F. Pessaux, Type-based analysis of uncaught exceptions.
- R. Miller, A. Tripathi, Issues with Exception Handling in Object-Oriented Systems.
- S. Drew, K. J. Gough, J. Ledermann, Implementing Zero-Overhead Exception Handling.
- B. Stroustrup, Exception Safety: Concepts and Techniques.
- D. Malayeri, J. Aldrich, Practical Exception Specifications.
- H. Nakano, A Constructive Formalization of the Catch and Throw Mechanism.
- A. Nanevski, A Modal Calculus for Exception Handling.
- P. de Groote, A Simple Calculus of Exception Handling.
- H. Thielecke, On Exceptions and Continuations in Presence of State.
- J. G. Riecke, H. Thielecke, Typed Exceptions and Continuations Cannot Macro-Express Each Other.
- M. van Dooren, E. Steegmans, Combining the Robustness of Checked Exceptions with the Flexibility of Unchecked Exceptions using Anchored Exception Declarations.
- J. A. Vaughan, A logical interpretation of Java-style exceptions.
- S. Marlow, S. Peyton Jones, A. Moran, Asynchronous Exceptions in Haskell.
- B. Jacobs, F. Piessens, Failboxes: Provably Safe Exception Handling.
Context
StackExchange Computer Science Q#16081, answer score: 8
Revisions (0)
No revisions yet.