Navigation:  Programming Cookbook > Exception Handling > General Categories of Exception >

Errors

Previous pageReturn to chapter overviewNext page

Errors represent exceptional conditions that are normally considered 'fatal'.

Errors are not normally resumable, though specific subclasses can be resumable if desired, an example being MessageNotUnderstood.

The default action for an unhandled error is to send an #onUnhandledError: message to the SessionManager. The development system session manager (DevelopmentSessionManager) implements this by popping up a walkback. The standard RuntimeSessionManager displays a message box, and then proceeds as specified by the user (there will be no OK/Cancel choice if the Error is not resumable).

Applications, which typically implement their own session manager to meet their own specific requirements, can provide alternative behaviour by overriding the #onUnhandledError: message appropriately.

The class Error represents the most general form of error exception. Instances of Error represent non-resumable exceptional conditions with an associated description. Error is an appropriate exception to raise where the condition is the result of an error which cannot be recovered (e.g. a violation of a basic invariant), but it is not specific enough for situations where recovery is desirable.

The majority of more specific exception classes will be found under Error, and this is where one is most likely to want to introduce one's own exception classes.