ExceptionHandling

This page for programming. See OrganizationExceptionHandling for what happens in organizations.

This discussion on Artima makes sense to me : http://www.artima.com/intv/except.html

Basically ... suppliers (ie. objects and their methods) should do a few simple, well defined things (specified in the contract ... hmmm). If they try to do too much, particularly if they try to return too many possible alternative results via a large number of typed-exceptions, then :

• a) they are more complex, and

• b) the calling code has to be more complex.

Aside : I think he's wrong about ReFactoring though. Refactoring in his discussion is just running the planning-generalizing-implementing cycle at a finer granularity. The advantage of the finer-granularity is not that it hides the design activity from the bean-counters. It's that it does it in the context of a lot more feedback (from the experience WorkingTheCode) and with the mind focused on the goals of this bit of functionality. Allowing a longer planning-generalizing-implementing loop means that the planning is done further from the implementing (so less informed about the code), and further from the requirements of the code (so more space to imagine requirements that never materialize))

Manageability thinks Gosling is wrong : http://www.manageability.org/blog/stuff/exception-debate-gosling-hejlsberg-both-wrong/view

See also :

• FailQuicklyAndObviously

• ProgrammingStuff

• BugTrackers