--- a/GenericException.st Fri May 06 04:57:10 2016 +0200
+++ b/GenericException.st Fri May 06 04:57:24 2016 +0200
@@ -47,16 +47,16 @@
documentation
"
Note:
- The instance based Signal framework is being replaced by
- class based exceptions.
- I.e. what used to be instances of Signal/QuerySignal is beeing
- rewritten into subclasses of Exception/Error/Query and Warning.
- Although the functionality is basically unchanged, the new
- class based exceptions are easier to instanciate (no need for
- creation in a classes initialize method), easier to use (no real
- need for SIgnal-constant accessors) and allow for easier parameter
- passing (not only a single parameter, but allows for individual
- exception subclasses to add additional state).
+ The instance based Signal framework is being replaced by
+ class based exceptions.
+ I.e. what used to be instances of Signal/QuerySignal is being
+ rewritten into subclasses of Exception/Error/Query and Warning.
+ Although the functionality is basically unchanged, the new
+ class based exceptions are easier to instanciate (no need for
+ creation in a classes initialize method), easier to use (no real
+ need for SIgnal-constant accessors) and allow for easier parameter
+ passing (not only a single parameter, but allows for individual
+ exception subclasses to add additional state).
GenericException and its subclasses implement the same protocol as Signal.
So class based exceptions may be implemented as subclasses of GenericException.
@@ -69,22 +69,22 @@
The handler block may perform various actions by sending corresponding messages
to the exception object. The following actions are possible:
- reject - don't handle this signal;
- another handler will be searched for,
- upper in the calling hierarchy
-
- proceed - return from the Signal>>raise, with nil as value
-
- proceedWith:val - same, but return val from Signal>>raise
-
- return - return from the Signal>>handle:do:, with nil as value
-
- returnWith:val - same, but return val from Signal>>handle:do:
- (this is also the handler's default,
- if it falls through; taking the handlerBlocks value
- as return value)
-
- restart - restart the Signal>>handle:do:, after repairing
+ reject - don't handle this signal;
+ another handler will be searched for,
+ upper in the calling hierarchy
+
+ proceed - return from the Signal>>raise, with nil as value
+
+ proceedWith:val - same, but return val from Signal>>raise
+
+ return - return from the Signal>>handle:do:, with nil as value
+
+ returnWith:val - same, but return val from Signal>>handle:do:
+ (this is also the handler's default,
+ if it falls through; taking the handlerBlocks value
+ as return value)
+
+ restart - restart the Signal>>handle:do:, after repairing
Via the Exception object, the handler can also query the state of execution:
where the Signal was raised, where the handler is, the signal which caused
@@ -92,18 +92,18 @@
parameter can be passed - the use is signal specific.
[instance variables:]
- signal <Signal> the signal which caused the exception
-
- parameter <Object> a parameter (if any) which was passed when raising
- the signal (only if raised with #raiseWith:aParameter)
-
- messageText <String> an messageText
- (usually the signals own messageText, but sometimes
- changed explicitely in #raiseWith:errorString:)
-
- suspendedContext <Context> the context in which the raise occured
-
- handlerContext <Context> the context of the handler (if any)
+ signal <Signal> the signal which caused the exception
+
+ parameter <Object> a parameter (if any) which was passed when raising
+ the signal (only if raised with #raiseWith:aParameter)
+
+ messageText <String> an messageText
+ (usually the signals own messageText, but sometimes
+ changed explicitely in #raiseWith:errorString:)
+
+ suspendedContext <Context> the context in which the raise occured
+
+ handlerContext <Context> the context of the handler (if any)
In case of an unhandled signal raise, Exceptions EmergenyHandler will be evaluated.
The default emergeny handler will enter the debugger.
@@ -111,53 +111,53 @@
For applications, which do not want Debuggers to come up, other handlers are
possible.
For example, to get the typical C++ behavior, use:
- Exception emergencyHandler:[:ex | Smalltalk exitWithCoreDump]
+ Exception emergencyHandler:[:ex | Smalltalk exitWithCoreDump]
Raising:
- two different raising messages are to be used,
- depending on whether the exception is proceedable or not
-
- For some stupid reason, someone decided that the raise-code checks if
- the raising messages matches to what the signal thinks is its proceedability.
- (i.e. not only do both the sender and the signal itself specify proceedability,
- this is checked by the raise code and a warning is generated if there is a mismatch)
- This used to be even worse (WrongProceedabilityError), but we relaxed this to
- a message sent to stderr.
-
- That means, that PROCEEDABLE signals must be raised with:
- raiseRequest
- and NON-PROCEEDABLE signals must be raised with:
- raise
-
- If you dont know/care as a raiser, you can use
- raiseSignal
- which checks for proceedability and sends the appropriate message.
- (sigh)
+ two different raising messages are to be used,
+ depending on whether the exception is proceedable or not
+
+ For some stupid reason, someone decided that the raise-code checks if
+ the raising messages matches to what the signal thinks is its proceedability.
+ (i.e. not only do both the sender and the signal itself specify proceedability,
+ this is checked by the raise code and a warning is generated if there is a mismatch)
+ This used to be even worse (WrongProceedabilityError), but we relaxed this to
+ a message sent to stderr.
+
+ That means, that PROCEEDABLE signals must be raised with:
+ raiseRequest
+ and NON-PROCEEDABLE signals must be raised with:
+ raise
+
+ If you dont know/care as a raiser, you can use
+ raiseSignal
+ which checks for proceedability and sends the appropriate message.
+ (sigh)
all of the 3 messages above come in various flavours:
- raiseXXX - do not pass any additional parameter;
- default messageText
-
- raiseXXXWith: - pass additional parameter;
- default messageText
-
- raiseXXXErrorString: - do not pass any additional parameter;
- given errorString
-
- raiseXXXWith:errorString:
- - pass any additional parameter;
- AND given errorString
+ raiseXXX - do not pass any additional parameter;
+ default messageText
+
+ raiseXXXWith: - pass additional parameter;
+ default messageText
+
+ raiseXXXErrorString: - do not pass any additional parameter;
+ given errorString
+
+ raiseXXXWith:errorString:
+ - pass any additional parameter;
+ AND given errorString
[see also:]
- Signal SignalSet QuerySignal
- Context Block
- Object DebugView
- (``Exception handling and signals'': programming/exceptions.html)
+ Signal SignalSet QuerySignal
+ Context Block
+ Object DebugView
+ (``Exception handling and signals'': programming/exceptions.html)
[author:]
- Claus Gittinger
+ Claus Gittinger
"
!
@@ -224,7 +224,6 @@
self raiseErrorString:messageText
! !
-
!GenericException class methodsFor:'accessing'!
errorString