ExceptionVariance
From APIDesign
JaroslavTulach (Talk | contribs)
(New page: This essay is most useful when dealing with Checked exceptions as known from Java, however even in systems without compile time exception checking it may be useful. The same princi...)
Next diff →
Revision as of 17:21, 14 July 2016
This essay is most useful when dealing with Checked exceptions as known from Java, however even in systems without compile time exception checking it may be useful. The same principle of Covariance/Contravariance of Exceptions applies in any language.
When creating both sides of an API - e.g. its ClientAPI facade as well as its ProviderAPI part, it is interesting to note that the way one deals with exceptions is (or at least should be) different.
The biggest drawback of Checked exceptions in Java is when they force callers to catch them when there is no reasonable recovery. How we can prevent that? Well, the easiest thing is to not throw any checked exceptions to the client. Then the clients don't need to care about the exceptions in the compile time. Btw. I have to mention that I believe there are situations when clients should care about exceptions and use the checked exceptions. But, if we want to take things to the extreme and if we want to make life of out [[clueless] users of our API is easy as possible: the less of compile time checked exceptions we throw - the easier for them during compilation.
Follow
