Thanks a lot everybody for the reactions, this could become a nice discussion next Friday. All points raised are valid, I would like simple names and a compact multipurpose hierarchy too.
On 13 Apr 2011, at 19:39, Dale Henrichs wrote: > Some thoughts from an old man (started programming before exceptions of any > kind were available:) ... > > In the old days, error numbers had a place in the universe ... error numbers > of a certain range indicated specific errors and the "error handlers" could > check for a range or a specific error ... > > Today I think there is still a place for the notion of "error numbers". > > In Smalltalk I would use Symbols instead of numbers, but the idea would be to > use a concrete exception class to identify broad categories of error > conditions (i.e., FileStreamError) and a symbolic "reason code" to indicate > the specific error (i.e., #fileDoesNotExist, #fileExists, #cannotDelete, > etc.), that way an error handler can be written for FileStreamError and then > specific action take with respect to which "reason code" is involved, if such > action is needed. > > The main advantage of using reasonCodes over using a "class per error > condition" is that you can reduce the size of the Exception hierarchy to a > manageable size (GemStone has hundreds of error conditions, so we've resorted > to using "reason codes" to manage the size of the hierarchy). > > As Hernan hints, more often than not it is important to be very specific > about the error condition when signalling an error (a unique error message > per "per reason code" would be desirable), but the there are very few places > where the handler is going to be that specific ... > > In other words, if it is likely that programmers in the course of using an > application will be writing specific error handlers to distinguish between > the KeyNotFound and ValueNotFound condition, then classes should be created, > otherwise, the NotFoundException could be implemented with three reason > codes: #keyNotFound, #valueNotFound, and #elementNotFound and you'd get the > best of both worlds, explicit information at the signalling site and a much > smaller and more manageable Exception class hierarchy. > > Dale > > On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >> I think it is not a good idea to use the prefix Exception. We do not use >> the word "exception" in real life, so we should not do it on our systems. >> About the proposed hierarchy, the problem with having specific >> exceptions is that they are important for those who catch them, not for >> those who signal them. For example, besides the name, what is the >> difference between KeyNotFound or ValueNotFound? none. So, I think that >> the exception hierarchy should be grown from it uses, not created based >> on how or where they are signaled. >> >> my 2 cents :-) >> >> On Wed, Apr 13, 2011 at 1:55 PM, Miguel Cobá <[email protected] >> <mailto:[email protected]>> wrote: >> >> El mié, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribió: >> >> > And as Mariano pointed out, there should be a convention on the >> > naming: I am still not sure about suffixing the exception classes >> with >> > "Exception", but I guess this is a good thing to do. Though I >> must say >> > that I omitted it so far ;) and just put the verb there, but that can >> > be easily changed. >> >> I would say no to suffixes. Analogous to announcements, they shouldn't >> have the suffix. The name should be descriptive enough and intention >> revealing that the suffix isn't needed in most cases. For example, I >> think that >> >> DividedByZero >> >> is better than >> >> DividedByZeroException >> >> and no information is lost with the sorter name. Instead, DivideByZero >> isn't clear enough to indicate that is a event that happened. >> >> What do you think? >> >> -- >> Miguel Cobá >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> >> >> >> >> -- >> *Hernán Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: [email protected] >> site: http://www.10Pines.com <http://www.10pines.com/>* >> > >
