On Apr 13, 2011, at 5:00 PM, Dale Henrichs wrote: > To say that "if one were to handle the KeyNotFoundException, they will need > the complete context", I prefer to say "Until one needs the complete context > of the KeyNotFoundException, don't bother creating class"
I hope (as an outsider) that this advice is taken seriously during this important refactoring effort. Designing the hierarchy is very much a what-color-should-the-bike-shed-be question. Usually the way it plays out on in day-to-day use is not gratitude towards the benevolent API designer for having provided such precise and helpful exception classes or rage towards the careless API designer for making them so unhelpful. No, In my experience it is much more likely to be, swearing at the API designer for having made exception handling an important (but substantially less discoverable) part of the API that must be mastered alongside the ordinary message protocol. A lesson from Java is that if you provide a rich, complex exception hierarchy with lots of specific exceptions, people will feel like they should be using them, even if they're never used in the system, poorly defined, or represent too broad a category (I'm looking at you, IllegalStateException!) — Daniel Lyons
