eXept Software AG Logo

Smalltalk/X Webserver

Documentation of class 'GenericException':

Home

Documentation
www.exept.de
Everywhere
for:
[back]

Class: GenericException


Inheritance:

   Object
   |
   +--GenericException
      |
      +--ControlInterrupt
      |
      +--Exception
      |
      +--NoHandlerError
      |
      +--Notification

Package:
stx:libbasic
Category:
Kernel-Exceptions
Version:
rev: 1.188 date: 2018/05/08 11:09:57
user: cg
file: GenericException.st directory: libbasic
module: stx stc-classLibrary: libbasic
Author:
Claus Gittinger

Description:


Note:
    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 instantiate (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.

Normally all exceptions are subclasses of Exception. Exceptions, that are
used for debugging or that are signalling errors in the exception system itself
are direct subclasses of GenericException.

Instances of Exception are passed to a Signal handling block as argument.
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

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
the error and the messageText passed when the signal was raised. Also, an optional
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 occurred

    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.

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]


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 don't 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


Related information:

    Signal
    SignalSet
    QuerySignal
    Context
    Block
    Object
    DebugView
    [``Exception handling and signals'']

Class protocol:

Compatibility-ANSI
o  signal
raise a signal proceedable or nonproceedable (whichever is right).
ANSI compatibility.

o  signalWith: messageText
raise a signal proceedable or nonproceedable (whichever is right).
The argument is used as messageText.
ANSI compatibility.

Compatibility-Dolphin
o  signal: messageText
( an extension from the stx:libcompat package )
raise a signal proceedable or nonproceedable (whichever is right).
The argument is used as messageText.

accessing
o  errorString
#errorString is deprecated, use description instead

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  handlerBlock
Compatibility with Signal. Class based exceptions do not have a handler
block. They redefine the #action method instead

o  notifierString: aString

backward compatibility
o  abortingEmergencyHandler
WARNING: this method belongs to NoHandlerError, and has been moved there

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  dumpingEmergencyHandler
WARNING: this method belongs to NoHandlerError, and has been moved there

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  emergencyHandler
WARNING: this method belongs to NoHandlerError, and has been moved there

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  emergencyHandler: aOneArgBlock
WARNING: this method belongs to NoHandlerError, and has been moved there

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  mailingEmergencyHandler
WARNING: this method belongs to NoHandlerError, and has been moved there

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  notifyingEmergencyHandler
WARNING: this method belongs to NoHandlerError, and has been moved there

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  notifyingEmergencyHandlerForUserProcesses
WARNING: this method belongs to NoHandlerError, and has been moved there

** This is an obsolete interface - do not use it (it may vanish in future versions) **

child signal creation
o  newSignal
create a new signal, using the receiver as a prototype and
setting the parent of the new signal to the receiver.

o  newSignalMayProceed: mayProceedBoolean
create a new signal, using the receiver as a prototype and
setting the parent of the new signal to the receiver.

converting
o  , anExceptionHandler
return a SignalSet with myself and anExceptionHandler

initialization
o  initialize
force strict signal checking in Smalltalk development - nobody cares otherwise

instance creation
o  js_new: errorString
( an extension from the stx:libjavascript package )
sent from js in:
throw new Error(msg)

usage example(s):
     (Error js_new:'hello') raise

o  new
(comment from inherited method)
return an instance of myself without indexed variables

o  newException

misc ui support
o  iconInBrowserSymbol
( an extension from the stx:libtool package )
the browser will use this as index into the toolbariconlibrary

printing
o  description
return the notifier string.
If the notifier string starts with space, prepend
the parents notifier string.
Subclasses may redefine this method.
usage example(s):
     Object errorSignal description

o  nameForDescription
if no notifierString is specified, this is used.
Can be redfined to hide the namespace in subclasses

o  printBadExceptionHandler: badExceptionHandler in: aContext
if anyone does:
[ xxx ] on: foo do:[ ... ]
with a bad foo (i.e. nil or not an Exception, ExceptionSet, Signal or HandlerSet
this method is called to print a warning.
Usually, this happens when foo is misspelled or when porting code
from Squeak, and there is no such exception-class in ST/X.
A typical situation is:
[ xxx ] on: NetworkError do:[ ... ]

queries
o  accepts: aSignal
return true, if the receiver accepts the argument, aSignal.
(i.e. the receiver is aSignal or a parent of it). False otherwise.

o  exception: anException isHandledIn: aContext
return true, if there is a handler for anException in the
contextChain starting with aContext.

o  exceptionHandlerFor: anException in: aContext
answer the exceptionHandler-block for anException from aContext.

o  handlerContextForException: anException in: aContext
return a handlerContext for anException in the
contextChain starting with aContext.
Returns nil, if there is no handler.

o  handlerForSignal: signal context: theContext originator: originator
answer the handler block for the signal from originator.
The block is retrieved from aContext.
Answer nil if the signal is not handled

o  handlerProtectedBlock: doBlock inContext: context
set the handlerProtectedBlock in context

o  handles: anException
return true, if the receiver handles the argument, anException.
(i.e. the receiver is anExceptions signal or a parent of it)

o  isHandled
return true, if there is a handler for the receiver signal.
Raising an unhandled signal will usually lead into the debugger,
but can be caught globally by setting Exceptions EmergencyHandler.

o  isHandledIn: aContext
return true, if there is a handler for the receiver signal in the
contextChain starting with aContext.

o  parent
return the parent Signal/Exception of myself.
Subclasses may redefine this to install themself as child of
existing Signals.

raising
o  raise
raise a signal nonproceedable.
The signals notifierString is used as messageText.

o  raiseAsQuery
utility to avoid code duplication.
raise the exception as a query. This means, that if it is unhandled,
a default value is returned (i.e. an implicit resume).
Return the handler's value (if there is one), or the default value, if not.
Invoking the handler is exactly the functionality of Signal>>raiseRequest,
but we can do it faster here (avoiding the construction of an exception instance).

o  raiseErrorString: aString
raise a signal nonproceedable.
The argument is used as messageText.

o  raiseErrorString: aString in: aContext
raise a signal nonproceedable.
The argument is used as messageText.

o  raiseFrom: something
raise a signal nonproceedable.
The argument, something is passed both as parameter and originator.

o  raiseIn: aContext
raise a signal nonproceedable.
The signals notifierString is used as messageText.

o  raiseRequest
raise a signal proceedable.
The signals notifierString is used as messageText.

o  raiseRequestErrorString: aString
raise a signal proceedable.
The argument, aString is used as messageText.

o  raiseRequestFrom: something
raise a signal proceedable.
The argument, something is passed both as parameter and originator.

o  raiseRequestIn: aContext
raise a signal proceedable.
The signals notifierString is used as messageText.

o  raiseRequestWith: aParameter
raise a signal proceedable.
The signals notifierString is used as messageText.

o  raiseRequestWith: aParameter errorString: aString
raise a signal proceedable.
The argument, aString is used as messageText.

o  raiseRequestWith: aParameter errorString: aString in: aContext
raise a signal proceedable.
The argument, aString is used as messageText.
The additional context is passed as the context responsible for the raise,
allowing a raise to mimicri the exception happened somewhere else.

o  raiseRequestWith: aParameter in: aContext
raise a signal proceedable.
The additional context is passed as the context responsible for the raise,
allowing a raise to mimicri the exception happened somewhere else.

o  raiseSignal
raise a signal (proceedable or not, whatever the proceedability is).
The signals notifierString is used as messageText.

o  raiseSignal: errorMessage
ANSI: raise a signal (proceedable or not, whatever the proceedability is).
The argument, errorMessage is used as messageText.

o  raiseSignal: errorMessage with: aParameter
ANSI: raise a signal (proceedable or not, whatever the proceedability is).
The argument, errorMessage is used as messageText.

o  raiseSignalErrorString: aString
raise a signal (proceedable or not, whatever the proceedability is).
The argument, aString is used as messageText.

o  raiseSignalWith: aParameter
raise a signal (proceedable or not, whatever the proceedability is).
The argument, aParameter is passed as parameter.

o  raiseSignalWith: aParameter errorString: aString
raise a signal (proceedable or not, whatever the proceedability is).
The argument, aString is used as messageText,
aParameter is passed as exception parameter.

o  raiseWith: aParameter
raise a signal nonproceedable.
The argument, aParameter is passed as parameter.

o  raiseWith: aParameter errorString: aString
raise a signal nonproceedable.
The argument, aString is used as messageText,
aParameter is passed as exception parameter.

o  raiseWith: aParameter errorString: aString in: aContext
raise a signal nonproceedable.
The argument, aString is used as messageText, aParameter is passed
as exception parameter.
The additional context is passed as the context responsible for the raise,
allowing a raise to mimicri the exception happened somewhere else.

o  raiseWith: aParameter in: aContext
raise a signal nonproceedable.
The argument, aParameter is passed as exception parameter.
The additional context is passed as the context responsible for the raise,
allowing a raise to mimicri the exception happened somewhere else.

save evaluation
o  catch: aBlock
evaluate the argument, aBlock.
If the receiver-exception is raised during evaluation, abort
the evaluation and return true; otherwise return false.
This is the catch & throw mechanism found in other languages,
where the returned value indicates if an exception occurred.
usage example(s):
     Object messageNotUnderstoodSignal catch:[
        123 size open
     ]

o  deferAfter: aBlock
evaluate the argument, aBlock.
Ignore the receiver-exception during evaluation - i.e. simply continue,
but remember if the signal was raised.
After the block evaluation, finally raise the signal - if it was raised in the block.
If the signal is raised multiple times, only the first raises parameter is remembered,
and only a single raise is performed after the blocks evaluation.

Deferring makes sense for some signals, such as UserInterrupt or AbortSignal,
which must occasionally be delayed temporarily until a save place is reached
(especially when packages are sent across a communication channel, and you don't want
partial packages to be generated by user interruptions).
usage example(s):
     UserInterrupt deferAfter:[
         Transcript showCR:'1 - now raising, but will be deferred.'.
         UserInterrupt raiseRequestWith:'hello'.
         Transcript showCR:'2 - after the raise, deferred exception will be handled soon.'.
     ].
     Transcript showCR:'3 - here after the protected block.'.

o  evaluate: aBlock ifRaised: exceptionValue
evaluate the argument, aBlock and return its value.
If the receiver-signal is raised during evaluation, abort
the evaluation and return the value from exceptionValue.
This is similar to the catch & throw mechanism found in other languages
usage example(s):
     MessageNotUnderstood
        evaluate:[ 123 size open ]
        ifRaised:345

o  handle: handleBlock do: aBlock
evaluate the argument, aBlock.
If the receiver-exception is raised during evaluation,
evaluate the handleBlock passing it an Exception argument.
The handler may decide how to react to the signal by sending
a corresponding message to the exception (see there).
If the signal is not raised, return the value of evaluating
aBlock.
usage example(s):
     Object messageNotUnderstoodSignal handle:[:ex |
	'oops' printNL.
	ex return
     ] do:[
	123 size open
     ]

o  handle: handleBlock from: anObject do: aBlock
evaluate the argument, aBlock.
If the receiver-exception is raised during evaluation,
and the exception originated from anObject,
evaluate the handleBlock passing it an Exception argument.
The handler may decide how to react to the signal by sending
a corresponding message to the exception (see there).
If the signal is not raised, return the value of evaluating
aBlock.

o  ignoreIn: aBlock
evaluate the argument, aBlock.
Ignore the receiver-exception during evaluation - i.e. simply continue with the default resume value.
This makes only sense for some signals, such as UserInterrupt
or AbortOperationRequest, because continuing after an exception without any cleanup
often leads to followup-errors.
usage example(s):
     Object messageNotUnderstoodSignal ignoreIn:[
        123 size open
     ]

     DomainError ignoreIn:[ -1.0 log10 ]

testing
o  isAbstract

o  isControlInterrupt

o  isExceptionCreator
return true, if the receiver can create exceptions,
this includes #raise, #raiseRequest as well as the behavior of
an exception handler, such as the #accepts: and #handles: messages

o  isExceptionHandler
return true, if the receiver responds to the exception handler protocol,
especially to the #accepts: and #handles: messages

o  isProgramError
redefined in all exceptions which are programmer's errors,
and which should probably not be ignored.
I.e. a global error handler should reject and let a debugger get control.

o  isQuery
return true, if this is a query - always return false here

o  isQuerySignal
return true, if this is a querySignal - always return false here

o  mayProceed
return true, if the exception handler is allowed to proceed
the execution where the exception occurred.

Subclasses may redefine this.


Instance protocol:

Compatibility-ANSI
o  pass
same as reject - for ANSI compatibility

o  retry
same as #restart - ANSI & VW compatibility

o  retryUsing: alternativeBlock
Abort an exception handler and evaluate a new block in place of the handler's protected block.

o  signal
raise a signal proceedable or nonproceedable (whichever is right).
ANSI compatibility.
usage example(s):
     Error new signal
     Error new raiseSignal

o  signalWith: messageTextArg
raise a signal proceedable or nonproceedable (whichever is right).
The argument is used as messageText.
ANSI compatibility.

Compatibility-Dolphin
o  stackTrace: numberOfFrames
return a backtrace information string
usage example(s):
     Error handle:[:ex |
	(ex stackTrace:20) inspect.
     ] do:[
	self error
     ].

Compatibility-Squeak
o  signal: aString
( an extension from the stx:libcompat package )

o  signalerContext
return the context in which the raise occurred.
Same as suspendedContext, for squeak compatibility

Compatibility-V'Age
o  exitWith: value
return with a value.
V'AGE compatibility.

accessing
o  catchInDebugger
if set, the debugger will handle this signal in its event loop and will close itself
without asking for close-confirmation.
This allows for debugged processes to be terminated without a user confirmation dialog
(for now, this is used in expecco's hard-terminate function to shut down any open debuggers
together with the test-process).
Dummy here

o  catchInDebugger: aBoolean
if set, the debugger will handle this signal in its event loop and will close itself
without asking for close-confirmation.
This allows for debugged processes to be terminated without a user confirmation dialog
(for now, this is used in expecco's hard-terminate function to shut down any open debuggers
together with the test-process).
Dummy here

o  creator
return the creator of the exception.
For class based exceptions, that is the exception class;
for signals, that is the signal itself.
This used to be called 'signal' in earlier versions,
but due to the conflict with VSE, Squeak and others,
where 'signal' means 'raise', 'signal' was obsoleted by this method.

o  errorString
return the errorString passsed with the signal raise
(or nil, if there was none).
#errorString is the same as description,
which returns the messageText plain or appended or prepended to the
classes description string.

o  errorString: aString
set the messageText.
If it starts with a space, the signals messageText is prepended,
if it ends with a space, it is appended.

#errorString: does the same as messageText:,
but should be used for errors and exceptions,
whereas messageText: should be used for notifications and queries

o  handler
return the exception handler (Signal or SignalSet or ExceptionHandlerSet or Exception)
that handles the exception.
This is only valid during handler evaluation, and answers
the object which accepted the actual exception.
usage example(s):
      [
	  2 // 0
      ] on:Error do:[:ex| ex handler inspect]

      [
	  2 // 0
      ] on:ArithmeticError, Error do:[:ex| ex handler inspect]

      [
	  2 // 0
      ] on:MessageNotUnderstood do:[:ex| ex handler inspect]
	on:Error do:[:ex| ex handler inspect]

o  handlerContext
return the context of the handler

o  handlingException

o  isResumable
return true, if the exception is resumable

o  isResumable: aBoolean

o  messageText
return the explicit given messageText - nil, if signaler did not provide one.

o  messageText: aString
set the messageText.
If it starts with a space, the signal's original messageText is prepended,
if it ends with a space, it is appended.

messageText: does the same as errorString:,
but should be used for notifications and queries,
whereas errorString: should be used for errors and exceptions

o  originalSignal
return the signal/exception which was originally raised.
For noHandler, that is my unhandled signal; for others, that's the exception itself.

o  originator
return the originator passsed with the signal raise
(or nil, if there was none)

o  originator: anObject
set the originator

o  parameter
return the parameter passsed with the signal raise
(or nil, if there was none)

o  parameter: anObject
set the parameter of the exception

o  proceedable: aBoolean
explicitly change the proceedability.
Normally this gets initialized from the classes idea of whether this makes sense

o  raiseContext

o  rejected
return true, if any other of the exception's handlers has rejected
Uncertain, if this is really interesting to anybody.
This is only valid during handler execution.
(i.e. an outer handler can find out, if any other handler has already rejected).
Currently only used to change the 'unhandled-exception' messageText
into 'rejected-exception' for the information, that there was a handler which rejected.

o  returnableSuspendedContext
return a nearest returnable context above suspendedContext in the sender chain.
We know, that raiseContext is always returnable, so if suspendedContext
is non-returnable, start there

o  searchFrom: raisingContext

o  suspendedContext
return the context in which the raise occurred

o  suspendedContext: something
set the value of the instance variable 'suspendedContext' (automatically generated)

o  willProceed
return true, if the exception is proceedable

copying
o  postCopy
set the internal state to nil

o  postDeepCopy
set the internal state to nil

default actions
o  defaultAction
perform a action for the exception if it hasn't been catched
We arrive here, if either no handler was found, or none of the
handlers did a return (i.e. every handler rejected).

The default is to evaluate the signal's handlerBlock or
to raise the noHandlerSignal.
Subclasses may redefine this.

o  mayProceed
return true, if the exception handler is allowed to proceed
the execution where the exception occurred.

Subclasses may redefine this.

o  noHandler
raise the NoHandlerError.
NohandlerError redefines this method to avoid recursive invocations

default values
o  defaultResumeValue
the default answer, if no one handles the query and the exception is resumed

o  defaultReturnValue

handler actions
o  exit
either resume or return - depending on the receiver's resumability.
VW compatibility.

o  exit: value
either resume or return - depending on the receiver's resumability.
VW compatibility.

o  proceed
Continue after the raise - the raise returns nil

o  proceedWith: value
Continue after the raise - the raise returns value

o  reject
handler decided not to handle this signal -
system will look for another handler
usage example(s):
returning form the doCallXX: signals a reject
usage example(s):
     Error handle:[:ex |
	'1' printCR.
	ex reject
     ] do:[
	Error handle:[:ex |
	    '2' printCR.
	    ex reject
	] do:[
	    #() at:1
	]
     ]

o  resignalAs: anotherException
resignal anotherException, as if it was raised in the first place

o  restart
restart the handle:do: - usually after some repair work is done
in the handler
usage example(s):
con restart

o  restartDo: aBlock
restart the handle:do: but execute the argument, aBlock instead of the
original do-block - usually after some repair work is done in handler

o  resume
Continue after the raise - the raise returns defaultResumeValue - ANSI

o  resume: value
Continue after the raise - the raise returns value - ANSI

o  resumeWith: value
Continue after the raise - the raise returns value - ANSI

o  return
Continue after the handle:do: - the handle:do: returns nil
usage example(s):
when a normal return is done. As unwind actions are called,

o  return: value
Continue after the handle:do: - the handle:do: returns value

o  returnDoing: aBlock
Continue after the handle:do: - the handle:do: returns aBlock value
Be careful when debugging. You cannot see the context with #returnDoing:
in the debugger if aBlock raises a signal
usage example(s):
	[
	    5 // 0
	] on:Error do:[:ex|
	    ex returnDoing:[self halt. 47*11].
	]

o  returnWith: value
Continue after the handle:do: - the handle:do: returns value

printing & storing
o  description
return the description string of the signal/exception.
If a messageText has been set, that is returned plain, appended or prepended to the
classes description string.
usage example(s):
      (Error new messageText:'bla') description
      (Error new messageText:' bla') description
      (Error new messageText:'bla ') description

o  descriptionForDebugger
return the description string of the signal which is used in the
debugger title area

o  printOn: aStream

private
o  checkProceedable
helper for all raiseRequest methods

o  doCallAction
call the action proper
- needed an extra method to have a raise-marked context around
i.e. do not inline this into #doRaise !
(see implementation of #reject and #proceed).

o  doCallHandler: aHandlerBlock
call the handler proper - if the handler falls through, return the handler's value
- an extra method is needed to have a raise-marked context around.
i.e. do not inline this into #doRaise !
(see implementation of #reject and #proceed).
- also redefinable (see CascadingNotification)

o  doRaise
search through the context-calling chain for a handle-context
to the raising signal, a parent of it, or a SignalSet which includes
the raising signal.
If found, ask the receiver for the handler and evaluate
it with the receiver exception as argument.
If no handler is found, perform the default #action method.

ATTENTION: the code below depends on being called by #raise or
#raiseRequest for proper operation (it skips the sending context).

raising
o  raise
actually raise a non-proceedable exception

o  raiseErrorString: aString
raise the signal nonproceedable.
The argument, aString is used as messageText

o  raiseErrorString: aString in: aContext
raise the signal nonproceedable.
The argument, aString is used as messageText

o  raiseIn: aContext
actually raise a non-proceedable exception

o  raiseRequest
actually raise a proceedable exception.

o  raiseRequestErrorString: errorString in: aContext
actually raise a proceedable exception.

o  raiseRequestIn: aContext
actually raise a proceedable exception.

o  raiseRequestWith: aParameter errorString: aString
raise the signal proceedable.
The argument, aString is used as messageText,
aParameter is passed as exception parameter.

o  raiseRequestWith: aParameter errorString: aString in: aContext
actually raise a proceedable exception.

o  raiseRequestWith: aParameter in: aContext
actually raise a proceedable exception.

o  raiseSignal
actually raise an exception (whatever the proceedability is).

o  raiseWith: aParameter errorString: aString
raise the signal nonproceedable.
The argument, aString is used as messageText,
aParameter is passed as exception parameter.

o  raiseWith: aParameter errorString: aString in: aContext
raise the signal nonproceedable.
The argument, aString is used as messageText

o  raiseWith: aParameter in: aContext
raise the signal nonproceedable.
The argument, aString is used as messageText

setup
o  creator: aSignal
set the fields usable for inspection by the handler
- only to be sent from the signal when raising.

o  suspendedContext: sContext errorString: aString
set required fields
- only to be sent from the signal when raising

o  suspendedContext: aContext messageText: aString parameter: aParameter originator: anOriginator

o  suspendedContext: sContext parameter: aParameter
set required fields
- only to be sent from the signal when raising

o  suspendedContext: sContext parameter: aParameter errorString: aString
set required fields
- only to be sent from the signal when raising

o  suspendedContext: aContext parameter: aParameter originator: anOriginator

testing
o  isError

o  isException
(comment from inherited method)
answer true, if this is an Exception

o  isNotification

o  isProgramError
redefined in all exceptions which are programmer's errors,
and which should probably not be ignored.
I.e. a global error handler should reject and let a debugger get control.

o  isQuery


Examples:


Examples on Exception-raising & handling are found in the doc/coding section (CodingExamples). The emergencyHandler stuff is very useful, to prevent endUser applications from entering the debugger. See the examples in NoHandlerError.

ST/X 7.1.0.0; WebServer 1.663 at exept.de:8081; Mon, 20 Aug 2018 15:01:08 GMT