ExceptionVariance
From APIDesign
(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...) |
|||
| Line 3: | Line 3: | ||
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 [[exception]]s is (or at least should be) different. | 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 [[exception]]s is (or at least should be) different. | ||
| - | The biggest drawback of [[Checked exception]]s in [[Java]] is when they force callers to catch them | + | The biggest drawback of [[Checked exception]]s in [[Java]] is when they force callers to catch them and there is no reasonable recovery. How we can prevent that? Well, the easiest thing is to not throw any [[checked exception]]s to the client. Then the clients don't need to care about the exceptions at compile time. Btw. [[I]] have to mention that [[I]] believe there are situations when clients should care about [[exception]]s and then use the [[checked exception]]s seems OK. But, if we want to take things to the extreme and if we want to make life of our [[clueless] [[API]] users absolutely [[exception]]-checkless: the less of [[checked exception|compile time checked exception]]s we throw - the easier for them during compilation. |
Revision as of 17:27, 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 and 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 at compile time. Btw. I have to mention that I believe there are situations when clients should care about exceptions and then use the checked exceptions seems OK. But, if we want to take things to the extreme and if we want to make life of our [[clueless] API users absolutely exception-checkless: the less of compile time checked exceptions we throw - the easier for them during compilation.
Follow
