Camillo,
Hey, I _am_ old, but not _that_ old:) ... There are a couple of things
that were invented in the Stone Age that have survived to today, so old
ideas are not immediately bad, because they are old:)
It feels like you are creating classes that are not much more than
symbols ...
I am not one to shy away from using classes when they are called for,
but I am just making a practicality point ... we don't have a unique
class for each character in the alphabet, but we could....we could have
a unique class for every possible error condition or not ...
I think it is simply a practical answer...
I do maintain that you _should_ use some sort of test along the lines
of: "Will anyone ever need to write a handler for the exception?" in
your criteria for deciding when to create a class and when to use
something like a "reason code" to disambiguate the signalling site...
Dale
On 04/13/2011 12:32 PM, Camillo Bruni wrote:
Perfect, I ll be there to bang heads ;).
So without "Exception" pre- or suffix seems to be nice. However I
don't see the need of using symbols over real classes. This feels
indeed like going to stone age of error handling, thats what you have
polymorphism and ExceptionSets for.
Anyway, the main idea is to make single exceptions recognizable and
not just use one single, basically meaningless, exception type.
best regards, Camillo Bruni
On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote:
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/>*
