Re: [ecf-dev] Exception propagation during file transfer

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Thomas,

Thomas Hallgren wrote:
> Hi,
> I'm having some trouble understanding how to propagate exceptions 
> during file transfer.
>
> I have a IFileTransferListener implementation that listens to 
> IIncomingFileTransferReceiveStartEvent. When encountered, it passes a 
> File handle to my desired destination using the receive() method. This 
> receive method in turn is declared with a throws IOException clause. 
> My handleTransferEvent is not allowed to throw any exception at all.
>
> Unless I want to handle the exception right there and then, my only 
> option is to throw a RuntimeException. The exception can later be 
> accessed from my IFileTransfer which is what I want, but why force the 
> use of a RuntimeException?

The intention was to encourage/force the handling of the exception there 
(in handleTransferEvent).  The main reason is that since the job is 
actually created by the file transfer instance, and handleTransferEvent 
is called by that job/thread, there really isn't anywhere else on the 
stack to propagate the exception *to*. 
Since there is no client controlled calling thread that is waiting on 
file transfer completion to handle the exception higher up the stack, 
the implementation of handleTransferEvent is the last place in the stack 
for the exception to be handled by the application.

> I think that a more flexible approach would be to let the 
> handleTransferEvent throw a CoreException and an IOException (since 
> those two would cover most needs). An alternative would be to allow 
> the InvocationTargetException but if that is used the 
> IFileTransfer.getException() must be changed to return a Throwable.

I'm overstating the above paragraph a *little* bit.  What I mean by this 
is that we *could* add throwing CoreException (and/or IOException) to 
the handleTransferEvent, and the job that calls this method (defined in 
AbstractRetrieveFileTransfer) could catch this exception, simply log it, 
and then return a status of IStatus.ERROR for the job created.  But that 
wouldn't do too much good for user interface code...which wouldn't then 
have any chance to do anything in response such exceptions.  That's 
really the reason why I wanted to force the handleTransferEvent 
implementer to handle any exceptions...rather than just passing it on 
assuming that someone else (ui code higher up the stack) would handle 
it...because in the asynchronous case there is not necessarily any other 
code to handle the exception higher up on the stack.

Thanks,

Scott