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/>*
