[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Exception propagation during file transfer
|
Hi Scott,
My use-case is perhaps a bit out of the ordinary. Here's what I want to do:
During a resolution/materialization from Buckminster, several jobs are
spawned that are tasked with different types of downloads. It is common
that the transitive resolution of one component results in parallel
resolution of its dependencies. During the resolution there are
junctions where things must come together so it's common to wait for a
family of jobs to complete.
As you can see, my setup is not completely asynchronous. I need to know
about completed downloads since the artifacts that are downloaded have
an impact on how the resolution is progressing. One thing that has a big
impact is of course if a download is failing. The failures are always
propagated and will typically result in the failure of a node higher up
in the resolution chain which in turns cancels not just the failing job,
but also all parallel jobs extending from that same point.
So in essence, I need two things. I need to be able to catch exceptions
during download and I need to be able to wait for a download to complete
and then deal with the exception that caused the termination (if any).
From the looks of it, this is partly implemented. An exception is
indeed passed on when I receive the
IIncomingFileTransferReceiveDoneEvent. But there's no way for me to set
it (unless I throw a RuntimeException).
It's not totally clear to me how to wait for a completion. Ideally, if
the FileTransferJob was accessible and if it did something intelligent
and configurable with the Job.belongsTo(Object family) method, then it
would be possible to assign a job family to it. That would make it very
easy to wait for the completion of a set of parallel downloads.
Regards,
Thomas Hallgren
Scott Lewis wrote:
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev