Transport Interface

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.