Apple Newton Programmer’s Newton 2.0 (for Newton 2.0) - Manual (Page 808)

C H A P T E R 2 2
Transport Interface
22-20 Using the Transport Interface
Error Handling 22
The default exception handling method implemented by protoTransport is
HandleThrow , which catches and handles exceptions resulting from any supplied
transport methods such as SendRequest and ReceiveRequest . You must
provide your own exception handler for any methods that you define, or you can
pass them to
HandleThrow , as follows:
try begin
... // do something
Throw();
onException |evt.ex| do
:HandleThrow();
end
When handling an exception, HandleThrow first calls IgnoreError to give
your transport a chance to screen out benign errors. If IgnoreError returns
true , HandleThrow returns nil and stops.
Assuming the error is not rejected by IgnoreError , HandleThrow next checks
to see if an item is currently being processed. If so, it sends your transport the
ItemCompleted message and returns true . Note that ItemCompleted calls
HandleError to display an error alert to the user. If no item is currently being
processed, HandleThrow sends the HandleError message itself to display an
error alert.
The HandleError method calls TranslateError to give your transport a
chance to translate an error code into an error message that can be displayed to the
user. If your transport can’t translate the error (for example, because it’s a
system-defined error) you should simply call the inherited
TranslateError
method, which handles system-defined errors.
Power-Off Handling 22
The protoTransport object registers a power-off handler with the system
whenever the transport is not in the idle state. If the system is about to power off,
this power-off handler sends the transport the
PowerOffCheck message.
The default PowerOffCheck method in protoTransport displays a slip
asking the user to confirm that it is OK to break the connection. Then, when the
power is about to be turned off, the system sends the transport the
CancelRequest message and waits until the transport is idle before turning the
power off.
You can override the default PowerOffCheck method if you wish.
There is also a power-on handler that sends a CancelRequest message to the
transport when the system turns on after shutting down unexpectedly while
the transport is active.