Improving Pharo's Exception Hierarchy

> Hi All,
>
> I have this idea that I would like to discuss on the next Pharo sprint and maybe start to implement if there is some consensus on it.
>
> It has been mentioned many times before on this list that Object>>#error: should be replaced by signalling specific Exceptions in as many cases as possible (or where it makes sense). Even today, there was http://code.google.com/p/pharo/issues/detail?id=3987 !
>
> I think the core system should set the example here, by defining a number of general purpose exceptions and by using them. Going over #error: senders will be a lot of work but can be done in incremental/Pharo steps.
>
> So I went over the current hierarchy, scanned quickly through their references and some #error: senders by fundamental classes and looked at some other Smalltalks. I came up with the following very rough draft of an extended hierarchy (** marks new exceptions). In between brackets are the instance variables. Of course, we have to discuss about naming, instance variables and opportunities for reuse and inheritance (could be fun).
>
> I am no expert on exceptions and would certainly like to learn more. I am probably overlooking some aspects. We have to keep this Smalltalk like, flexible, dynamic, not start mimicing other languages.
>
> Any step in this direction will be an improvement over the current situation. Really using them correctly throughout the system will take some time. Defining the hierarchy could be done rather quickly. Refactoring is always possible later on.
>
> Exception (messageText)
>  Abort
>  Error
>    ArithemticError
>      ZeroDivide (dividend)
>      FloatingPointException
>      RangeError ** (from, to)
>      NaNError **
>    FileStreamException (fileName)
>      FileDoesNotExistException (readOnly)
>      FileExistsException (fileClass)
>      CannotDeleteFileException
>      FileWriteError
>      FileReadError **
>      FileClosedException **
>      CannotAccessFileException **
>      ReadonlyFileException **
>    MessageNotUnderstood (message, receiver)
>    NonBooleanReceiver (object)
>    OutOfMemory
>    Halt
>      AssertionFailure
>      BreakPoint
>    SyntaxError ** !exists! (input, position)
>      NumberFormatException **
>    HeadlessError **
>    TimedOut ** (object, operation, timeout)
>    VerificationException
>    IllegalOperation ** (operation, object)
>    SizeMismatch (objects)
>    LowMemory ** (percentageFree)
>    SubclassResponsibility ** (message, receiver)
>    NotYetImplemented ** (message, receiver)
>    CannotInstanciate ** (class)
>    ReadOnlyObject ** (object)
>    OutOfFreeSpace ** (object, size)
>    InvalidArgument ** (message, receiver, argument)
>    NotIndexable ** (object)    
>    NoKeyedAccess ** (object)
>    NonIntegerIndex ** (receiver, index)
>    SubscriptOutOfBounds ** (receiver, index, from, to)
>    NotFoundException ** (receiver, object)
>      KeyNotFound **
>      ValueNotFound **
>      ElementNotFound **
>    StreamException (stream)
>      PositionError ** (index, from, to)
>      EndOfStream **
>      BeginOfStream **
>
> All feedback is welcome.
>
> Regards,
>
> Sven
>
>
>

> Hi All,
>
> I have this idea that I would like to discuss on the next Pharo sprint and maybe start to implement if there is some consensus on it.
>
> It has been mentioned many times before on this list that Object>>#error: should be replaced by signalling specific Exceptions in as many cases as possible (or where it makes sense). Even today, there was http://code.google.com/p/pharo/issues/detail?id=3987 !
>
> I think the core system should set the example here, by defining a number of general purpose exceptions and by using them. Going over #error: senders will be a lot of work but can be done in incremental/Pharo steps.
>
> So I went over the current hierarchy, scanned quickly through their references and some #error: senders by fundamental classes and looked at some other Smalltalks. I came up with the following very rough draft of an extended hierarchy (** marks new exceptions). In between brackets are the instance variables. Of course, we have to discuss about naming, instance variables and opportunities for reuse and inheritance (could be fun).
>
> I am no expert on exceptions and would certainly like to learn more. I am probably overlooking some aspects. We have to keep this Smalltalk like, flexible, dynamic, not start mimicing other languages.
>
> Any step in this direction will be an improvement over the current situation. Really using them correctly throughout the system will take some time. Defining the hierarchy could be done rather quickly. Refactoring is always possible later on.
>
> Exception (messageText)
>  Abort
>  Error
>    ArithemticError
>      ZeroDivide (dividend)
>      FloatingPointException
>      RangeError ** (from, to)
>      NaNError **
>    FileStreamException (fileName)
>      FileDoesNotExistException (readOnly)
>      FileExistsException (fileClass)
>      CannotDeleteFileException
>      FileWriteError
>      FileReadError **
>      FileClosedException **
>      CannotAccessFileException **
>      ReadonlyFileException **
>    MessageNotUnderstood (message, receiver)
>    NonBooleanReceiver (object)
>    OutOfMemory
>    Halt
>      AssertionFailure
>      BreakPoint
>    SyntaxError ** !exists! (input, position)
>      NumberFormatException **
>    HeadlessError **
>    TimedOut ** (object, operation, timeout)
>    VerificationException
>    IllegalOperation ** (operation, object)
>    SizeMismatch (objects)
>    LowMemory ** (percentageFree)
>    SubclassResponsibility ** (message, receiver)
>    NotYetImplemented ** (message, receiver)
>    CannotInstanciate ** (class)
>    ReadOnlyObject ** (object)
>    OutOfFreeSpace ** (object, size)
>    InvalidArgument ** (message, receiver, argument)
>    NotIndexable ** (object)    
>    NoKeyedAccess ** (object)
>    NonIntegerIndex ** (receiver, index)
>    SubscriptOutOfBounds ** (receiver, index, from, to)
>    NotFoundException ** (receiver, object)
>      KeyNotFound **
>      ValueNotFound **
>      ElementNotFound **
>    StreamException (stream)
>      PositionError ** (index, from, to)
>      EndOfStream **
>      BeginOfStream **
>
> All feedback is welcome.
>
> Regards,
>
> Sven
>
>
>

> Hi All,
>
> I have this idea that I would like to discuss on the next Pharo sprint and maybe start to implement if there is some consensus on it.
>
> It has been mentioned many times before on this list that Object>>#error: should be replaced by signalling specific Exceptions in as many cases as possible (or where it makes sense). Even today, there was http://code.google.com/p/pharo/issues/detail?id=3987 !
>
> I think the core system should set the example here, by defining a number of general purpose exceptions and by using them. Going over #error: senders will be a lot of work but can be done in incremental/Pharo steps.
>
> So I went over the current hierarchy, scanned quickly through their references and some #error: senders by fundamental classes and looked at some other Smalltalks. I came up with the following very rough draft of an extended hierarchy (** marks new exceptions). In between brackets are the instance variables. Of course, we have to discuss about naming, instance variables and opportunities for reuse and inheritance (could be fun).
>
> I am no expert on exceptions and would certainly like to learn more. I am probably overlooking some aspects. We have to keep this Smalltalk like, flexible, dynamic, not start mimicing other languages.
>
> Any step in this direction will be an improvement over the current situation. Really using them correctly throughout the system will take some time. Defining the hierarchy could be done rather quickly. Refactoring is always possible later on.
>
> Exception (messageText)
>  Abort
>  Error
>    ArithemticError
>      ZeroDivide (dividend)
>      FloatingPointException
>      RangeError ** (from, to)
>      NaNError **
>    FileStreamException (fileName)
>      FileDoesNotExistException (readOnly)
>      FileExistsException (fileClass)
>      CannotDeleteFileException
>      FileWriteError
>      FileReadError **
>      FileClosedException **
>      CannotAccessFileException **
>      ReadonlyFileException **
>    MessageNotUnderstood (message, receiver)
>    NonBooleanReceiver (object)
>    OutOfMemory
>    Halt
>      AssertionFailure
>      BreakPoint
>    SyntaxError ** !exists! (input, position)
>      NumberFormatException **
>    HeadlessError **
>    TimedOut ** (object, operation, timeout)
>    VerificationException
>    IllegalOperation ** (operation, object)
>    SizeMismatch (objects)
>    LowMemory ** (percentageFree)
>    SubclassResponsibility ** (message, receiver)
>    NotYetImplemented ** (message, receiver)
>    CannotInstanciate ** (class)
>    ReadOnlyObject ** (object)
>    OutOfFreeSpace ** (object, size)
>    InvalidArgument ** (message, receiver, argument)
>    NotIndexable ** (object)    
>    NoKeyedAccess ** (object)
>    NonIntegerIndex ** (receiver, index)
>    SubscriptOutOfBounds ** (receiver, index, from, to)
>    NotFoundException ** (receiver, object)
>      KeyNotFound **
>      ValueNotFound **
>      ElementNotFound **
>    StreamException (stream)
>      PositionError ** (index, from, to)
>      EndOfStream **
>      BeginOfStream **
>
> All feedback is welcome.
>
> Regards,
>
> Sven
>
>
>

> 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á <[hidden email]
> <mailto:[hidden email]>> 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: [hidden email]
> site: http://www.10Pines.com <http://www.10pines.com/>*
>

> 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á <[hidden email]
>> <mailto:[hidden email]>> 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: [hidden email]
>> site: http://www.10Pines.com <http://www.10pines.com/>*
>>
>
>

> 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á <[hidden email]
>>> <mailto:[hidden email]>> 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: [hidden email]
>>> site: http://www.10Pines.com <http://www.10pines.com/>*
>>>
>>
>>
>
>

> 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á<[hidden email] <mailto:[hidden email]>>
>>>> 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:
>>>> [hidden email] site:
>>>> http://www.10Pines.com<http://www.10pines.com/>*
>>>>
>>>
>>>
>>
>>
>
>

> 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á<[hidden email] <mailto:[hidden email]>>
>>>>> 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:
>>>>> [hidden email] site:
>>>>> http://www.10Pines.com<http://www.10pines.com/>*
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

> I find the "managing the exception hierarchy" a bit strange... Do you really
> have to manage anything more than just normal classes? Every exception is
> related to a specific part of your code, just like other classes. What's
> wrong with creating hundreds of small classes wherever it's necessary? You
> might save a tiny bit of memory by using error codes or symbols, but I don't
> really see much more of a gain there, while you do gain from proper objects.
>
> Being clear and modeling properly generally pays off in the long run. And
> the bit of runtime memory you save isn't really worth your while...
>
> Or am I missing something else? I didn't really follow the whole
> conversation in-depth.
>
> cheers,
> Toon
>
> On 04/13/2011 09:54 PM, Dale Henrichs wrote:
>>
>> 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á<[hidden email] <mailto:[hidden email]>>
>>>>>> 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:
>>>>>> [hidden email] site:
>>>>>> http://www.10Pines.com<http://www.10pines.com/>*
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>

> I find the "managing the exception hierarchy" a bit strange... Do you
> really have to manage anything more than just normal classes? Every
> exception is related to a specific part of your code, just like other
> classes. What's wrong with creating hundreds of small classes wherever
> it's necessary? You might save a tiny bit of memory by using error codes
> or symbols, but I don't really see much more of a gain there, while you
> do gain from proper objects.
>
> Being clear and modeling properly generally pays off in the long run.
> And the bit of runtime memory you save isn't really worth your while...
>
> Or am I missing something else? I didn't really follow the whole
> conversation in-depth.
>
> cheers,
> Toon
>
> On 04/13/2011 09:54 PM, Dale Henrichs wrote:
>> 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á<[hidden email]<mailto:[hidden email]>>
>>>>>> 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:
>>>>>> [hidden email] site:
>>>>>> http://www.10Pines.com<http://www.10pines.com/>*
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>