Class-based Exceptions best practice (or close)

Hi All,

As part of my work with the zip stuff I'm trying to learn a little about Class-based Exceptions.  Most of the exceptions that would be thrown are the result of getting an MZError or a CfsError.  Instead of extracting the message form the error adding some text to it and shoving that into the exception when it is signaled, I'm thinking of pushing the error into the exception and having the exception build the final description.  Am I off base here or breaking some convention?  Any ideas or guidance is appreciated.

Lou

As part of my work with the zip stuff I'm trying to learn a little about Class-based Exceptions.  Most of the exceptions that would be thrown are the result of getting an MZError or a CfsError.  Instead of extracting the message form the error adding some text to it and shoving that into the exception when it is signaled, I'm thinking of pushing the error into the exception and having the exception build the final description.  Am I off base here or breaking some convention?  Any ideas or guidance is appreciated.

Hi Richard,

Thanks for confirming my thoughts.  I was sure it was the right way to go but with conventions are not always the best way so I asked.  I have made the changes to the zip code and will follow up with a post in the other thread soon.

Lou

Richard wrote:

On Thursday, July 31, 2014 10:53:42 AM UTC-7, Louis LaBrunda wrote:

As part of my work with the zip stuff I'm trying to learn a little about Class-based Exceptions.  Most of the exceptions that would be thrown are the result of getting an MZError or a CfsError.  Instead of extracting the message form the error adding some text to it and shoving that into the exception when it is signaled, I'm thinking of pushing the error into the exception and having the exception build the final description.  Am I off base here or breaking some convention?  Any ideas or guidance is appreciated.

I would say that the option of preserving the entire original error object is good. Otherwise, you either copy all attributes from the object (breaking encapsulation and creating redundancy) or eventually discover one you didn't copy but need.

Hi Everybody,

Now that I'm an expert in class-based exceptions (put smiley face here) I thought I would report back on the experience.  I have used the instance-based exceptions in the past.  I find the class-based exception easier to use.  To make  instance-based exceptions easier to throw, they should be declared a global like in a pool dictionary.  Probably declared  in a PRAGMA.  Then you have to define the exception and set the value of the global.

With classed-based exceptions, you declare a new sub-class of Exception (or one of its sub-classes).  You set a few things like create class methods for #defaultDescription and #resumable and you are good to go.  In my case I wanted to set three arguments, so I added the class method #signalWith:with:with:.  It creates a new instance, sets the arguments and calls #signal.  I also overrode #signal on the instance side so I could use the arguments to construct the description/messageText I wanted.

I assume this is the way it was intended to work, anyway it worked well for me.

Lou

With classed-based exceptions, you declare a new sub-class of Exception (or one of its sub-classes).  You set a few things like create class methods for #defaultDescription and #resumable and you are good to go.  In my case I wanted to set three arguments, so I added the class method #signalWith:with:with:.  It creates a new instance, sets the arguments and calls #signal.  I also overrode #signal on the instance side so I could use the arguments to construct the description/messageText I wanted.

On Monday, August 4, 2014 10:17:51 AM UTC-7, Louis LaBrunda wrote:

With classed-based exceptions, you declare a new sub-class of Exception (or one of its sub-classes).  You set a few things like create class methods for #defaultDescription and #resumable and you are good to go.  In my case I wanted to set three arguments, so I added the class method #signalWith:with:with:.  It creates a new instance, sets the arguments and calls #signal.  I also overrode #signal on the instance side so I could use the arguments to construct the description/messageText I wanted.

With class-based exceptions, you can easily define your own behaviours and have them limited appropriately to the correct instances.

You can also avoid anonymous arguments. For example, in our earlier discussion, you talked about preserving the original CfsError instance. So one could easily have a #signalWithOriginalError: method rather than just call it #signalWith:. Simple example: look at ZeroDivide class>>#dividend:. It simply wraps a call to #signalWith:, making the calling code that much clearer, by being more explicit. And of course, there is the corresponding instance behaviour: ZeroDivide>>#dividend.

>> Maybe something like #signalWithOriginalError:filename:addedMessage:

>> or  #signalWithError:filename:addedMessage:
>> or  #signalWithError:filename:addedMsg:
>> or such to be a little shorter.

The first two seem reasonable, but avoid abbreviations unless absolutely necessary. They really hurt readability (just look at the "average" text message!).

Also, don't feel compelled to stick with "signal" as the verb. #error:inFileNamed:message: might make a reasonable choice; it plays on the Object>>#error "theme" to a degree. I'm not thrilled with that example, but you get the idea. If you want to keep "signal", perhaps #signalError:inFileNamed:message would work better.

On Wed, Aug 6, 2014 at 12:28 PM, Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dilubbmhH7kJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">L...@...> wrote:

Hey Richard,

On Wednesday, August 6, 2014 2:31:16 PM UTC-4, Richard Sargent wrote:

On Monday, August 4, 2014 10:17:51 AM UTC-7, Louis LaBrunda wrote:

With classed-based exceptions, you declare a new sub-class of Exception (or one of its sub-classes).  You set a few things like create class methods for #defaultDescription and #resumable and you are good to go.  In my case I wanted to set three arguments, so I added the class method #signalWith:with:with:.  It creates a new instance, sets the arguments and calls #signal.  I also overrode #signal on the instance side so I could use the arguments to construct the description/messageText I wanted.

With class-based exceptions, you can easily define your own behaviours and have them limited appropriately to the correct instances.

You can also avoid anonymous arguments. For example, in our earlier discussion, you talked about preserving the original CfsError instance. So one could easily have a #signalWithOriginalError: method rather than just call it #signalWith:. Simple example: look at ZeroDivide class>>#dividend:. It simply wraps a call to #signalWith:, making the calling code that much clearer, by being more explicit. And of course, there is the corresponding instance behaviour: ZeroDivide>>#dividend.

Good point!  I was probably following the method name pattern that I think came from the instance based exceptions that had names like #signalWith: and #signalWith:with: and friends.  Maybe something like #signalWithOriginalError:filename:addedMessage: or  #signalWithError:filename:addedMessage: or  #signalWithError:filename:addedMsg: or such to be a little shorter.

Lou

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/va-smalltalk/fVCSORmHFGg/unsubscribe" target="_blank" onmousedown="this.href='https://groups.google.com/d/topic/va-smalltalk/fVCSORmHFGg/unsubscribe';return true;" onclick="this.href='https://groups.google.com/d/topic/va-smalltalk/fVCSORmHFGg/unsubscribe';return true;">https://groups.google.com/d/topic/va-smalltalk/fVCSORmHFGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dilubbmhH7kJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">va-smalltalk...@....
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dilubbmhH7kJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">va-sma...@....
Visit this group at <a href="http://groups.google.com/group/va-smalltalk" target="_blank" onmousedown="this.href='http://groups.google.com/group/va-smalltalk';return true;" onclick="this.href='http://groups.google.com/group/va-smalltalk';return true;">http://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

How about #signalError:withFileNamed:message:?  I like the # #signalError: part because it says what the method will do.  I like the withFileNamed: part because it will work with both zip and unzip and their stages of processing that may be about the zip file or its component files.  The message: part could be more explicate because it is not the whole message but the name is getting long and message: will do.

On Wednesday, August 6, 2014 1:33:21 PM UTC-7, Louis LaBrunda wrote:

How about #signalError:withFileNamed:message:?  I like the # #signalError: part because it says what the method will do.  I like the withFileNamed: part because it will work with both zip and unzip and their stages of processing that may be about the zip file or its component files.  The message: part could be more explicate because it is not the whole message but the name is getting long and message: will do.

That looks pretty good to me.

Your concern about the name "message" leaves me wondering what is the nature of the "added message". There may be a less generic name that better reflects what its role is. Examples include "reason", "task", "activity". e.g., if the added message were explaining whether you were adding to the zip or extracting from it, the message might be more appropriately called task, activity, or something else more explicit than "message".

On Wednesday, August 6, 2014 4:53:21 PM UTC-4, Richard Sargent wrote:

... wondering what is the nature of the "added message". There may be a less generic name that better reflects what its role is. Examples include "reason", "task", "activity". e.g., if the added message were explaining whether you were adding to the zip or extracting from it, the message might be more appropriately called task, activity, or something else more explicit than "message".

The "message" can be any of those.  It is part of the text that is used to create the #description of the exception.  The description is constructed like so: '%1 "%2", %3.' bindWith: addedMessage with: withFileName with: messageFromError.  The added message starts the description followed by the file name of interest and the text from the error object.  Most of the places I signal an error from my code tend to be describing the "task" but nothing holds one to that.  I'm still open to suggestions and you have been a big help.

On Wednesday, August 6, 2014 2:30:17 PM UTC-7, Louis LaBrunda wrote:

On Wednesday, August 6, 2014 4:53:21 PM UTC-4, Richard Sargent wrote:

... wondering what is the nature of the "added message". There may be a less generic name that better reflects what its role is. Examples include "reason", "task", "activity". e.g., if the added message were explaining whether you were adding to the zip or extracting from it, the message might be more appropriately called task, activity, or something else more explicit than "message".

The "message" can be any of those.  It is part of the text that is used to create the #description of the exception.  The description is constructed like so: '%1 "%2", %3.' bindWith: addedMessage with: withFileName with: messageFromError.  The added message starts the description followed by the file name of interest and the text from the error object.  Most of the places I signal an error from my code tend to be describing the "task" but nothing holds one to that.  I'm still open to suggestions and you have been a big help.

I see. "message" does sound like the best choice here.

One alternative to consider, in general rather than for this specific situation, would be to pass the template to the signal... method. That would allow the possibility of some messages having more fill in the blanks than others. It doesn't sound like that would be needed here, so I think the somewhat anemic "message" is the best trade-off for brevity and clarity.

...  But it is nice to use method names that make sense and are helpful.  Thanks for being a sounding board for this.  This isn't rocket science but it can be hard to come up with good names.  In this case I didn't even think about the name until you brought it up.