Heuristics.RecentChanges
Edit Page
Page Revisions
|
SearchWiki Heuristics.RecentChanges Edit Page Page Revisions |
| Home Design Patterns Heuristics Software Development Software Process Patterns TheIntroduction LogicalDesign PhysicalDesign PatternFoundations GuidelinesAndMyths ReferenceImplementation DependencyPatterns UsabilityPatterns ExtensibilityPatterns MaintenancePatterns AntiPatterns UtilitiesAndTools AllPatterns | NameCollocateExceptionsStatementExceptions should be close to the classes that throw them.SketchDescriptionExceptions thrown within a component, that only the component knows about can be placed anywhere within the component since the exception class is hidden within the component. However, for those exceptions that trickle back to the user of the component (up the call stack), the exception class must be defined in a package at the same level as the class or interface that throws it. This is especially important if you have very StableComponents that are AbstractComponents. In this situation, the exception must be defined in the same component as the abstractions.Implementation VariationsThere seems to be a trend toward throwing all unchecked exceptions. Unchecked exceptions do not require the client to explicitly declare a try...catch block. Unfortunately, unless the client knows of the exception, it's likely the client will find out about the exception only when the exception is thrown. I haven't formed a strong opinion on whether using checked or unchecked exceptions is better, so it's largely left to the preference of the development team. However, whichever strategy you adopt, you should ensure consistency throughout the application and across components. It does seem to me though, that using unchecked exceptions, results in a very reactive programming style. You will only handle the exception once you are aware that it can be thrown. This is a tough lesson to learn if it's not thrown until your application or component reaches production.ConsequencesSample CodeRelated Pattern(s) |