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?
Is there a theory of exception hierarchies?
terminology;programming languages;api design