Next: Handling exceptions, Previous: Creating exceptions, Up: Exception handling
Raising an exception is really a two-step process. First, you create
the exception object; then, you send it #signal
.
If you look through the hierarchy, you’ll see many class methods
that combine these steps for convenience. For example, the class
Exception
provides #new
and #signal
, where the
latter is just ^self new signal
.
You may be tempted to provide only a signalling variant of your own exception creation methods. However, this creates the problem that your subclasses will not be able to trivially provide new instance creation methods.
Error subclass: ReadOnlyText [ ReadOnlyText class >> signalOn: aText range: anInterval [ ^self new initText: aText range: anInterval; signal ] initText: aText range: anInterval [ <category: 'private'> ... ] ]
Here, if you ever want to subclass ReadOnlyText
and add new
information to the instance before signalling it, you’ll have to use
the private method #initText:range:
.
We recommend leaving out the signalling instance-creation variant in new code, as it saves very little work and makes signalling code less clear. Use your own judgement and evaluation of the situation to determine when to include a signalling variant.