Signal>>#description changed for compatibility with class-based Exceptions
Reason for change
In VA Smalltalk, class- and instance-based exceptions should be able to be used interchangeably. This implies that the semantics of methods defined separately for class- and instance-based exceptions should be the same. Signal>>#description and Exception>>#description did not conform to this rule.
For instance-based exceptions, Signal>>#description answered the constant description string of the ExceptionalEvent that was set when the exception was created; for class-based exceptions, Exception>>#description answered either <className> or <className>’: ‘<messageText> depending on whether or not #messageText answered nil.
Change
Both class- and instance-based exceptions now answer a consistent value for #description -- <ee-description> or <ee-description>’: ‘<messageText> depending on whether or not #messageText answers nil.
<ee-description> is the string answered when sending exception description to an instance of Signal or any of its subclasses, and is the same string that was previously answered by Signal>>#description.
Notice that the string answered by #description differs both from the previous class- and instance-based exception implementations.
Examples
The following examples show the message string produced by the #description method before and after this change.
[ (Array with: 1) at: 2 ]
when: ExError do: [ :ex |
Transcript cr; show: ex description.
ex exitWith: nil ]
Before: (ExError) An error has occurred.
After: (ExError) An error has occurred.: Primitive failed in: Object>>#at: due to Index out of range in argument 1
[ self error: 'Could not do that because 15 screws are missing in the left wing' ]
on: ExError do: [ :ex |
Transcript cr; show: ex description.
ex exitWith: nil ]
Before: (ExError) An error has occurred.
After: (ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing
[ Object foo ]
on: ExError do: [ :ex |
Transcript cr; show: ex description.
ex exitWith: nil ]
Before: MessageNotUnderstood: Object class>>foo
After: (ExMessageNotUnderstood) An exception has occurred: Object class does not understand foo
Action required
It is unlikely that any action is required since the change is only to the exact format and content of the string answered by #description. However, some customers have implemented complex logic to handle the different values answered by #description and/or #messageText and this logic can now be either removed or significantly simplified.
•If your application is dependent on the exact format or content of the string that Signal>>#description previously returned, then you should update your application to send exception description rather than description to an instance of Signal or alternatively, adapt your application to the new string format and content.
•If your application is dependent on the exact format or content of the string that Exception>>#description previously returned, then you should adapt your application to the new string format and content.
Last modified date: 07/02/2019