Exception
From APIDesign
(Difference between revisions)
(New page: Java made checked exceptions popular topic of many debates. When designing a Java one is often confronted with the necessary choice between checked exceptions or runtime [[...) |
|||
| Line 1: | Line 1: | ||
| - | [[Java]] made [[checked exception]]s popular topic of many debates. When designing a [[Java]] one is often confronted with the necessary choice between [[checked exception]]s or runtime [[exception]]s. There are two camps who prefer the opposite solutions, with an attempt to bring some of rationality (and less [[cluelessness]]) into the discussion [[I]] have come up with a few [[:APIDesignPatterns:Exceptions|Exceptional API Design Patterns]]. | + | [[Java]] made [[checked exception]]s popular topic of many debates. When designing a [[Java]] one is often confronted with the necessary choice between [[checked exception]]s or runtime [[exception]]s. There are two camps who prefer the opposite solutions, with an attempt to bring some of rationality (and less [[cluelessness]]) into the discussion [[I]] have come up with a few [[:APIDesignPatterns:Exceptions|Exceptional API Design Patterns]] and organized them into [[:Category:APIDesignPatterns:Exceptions]] category. |
| + | |||
| + | [[Category:APIDesignPatterns:Exceptions]] | ||
Current revision
Java made checked exceptions popular topic of many debates. When designing a Java one is often confronted with the necessary choice between checked exceptions or runtime exceptions. There are two camps who prefer the opposite solutions, with an attempt to bring some of rationality (and less cluelessness) into the discussion I have come up with a few Exceptional API Design Patterns and organized them into Category:APIDesignPatterns:Exceptions category.
Follow
