Handling UploadException

Hello everyone,
I have some issues with the Upload component and particularly with the UploadException.

The users can upload some CSV files, I treat them directly in the receiver’s method “receiveUpload” (I don’t save the file on the file system, I don’t need to in these cases). If a file is corrupted or doesn’t match my expectations, the code throw a custom Exception that stop the receiveUpload method and fire the failedUpload event. I have a failedListener that show a notification to the user.

At this point, everything works but just after the failedListener has finished, an UploadException has thrown by the AbstractCommunicationManager and I don’t find how to handle it.
It bugs me because the error handler show the notification of an unhandled exception next to the upload button and I don’t know how to change this situation.

If you have any idea, please help me !! It’s not a blocking problem but it’s really annoying !
Thanks in advance.

MattU

I have a very similar problem using the Upload component in “immediate” mode. I finally tracked it down to what I believe is a bug. The ‘receiveUpload’ event listener is the logical place to test for file prerequisites, like whether it is the wrong MIME type or it is too large, etc. If you know right off the bat that the file is the wrong kind, you would just like to let the user know and not even try to upload it. Unfortunately, the Upload.Receiver interface (‘receiveUpload’) does not specify any way to indicate that the upload should not proceed (and neither the Java docs nor the Vaadin Book provide any information about how one should handle such situations). I had been invoking ‘interruptUpload’ on my Upload component and then returning null. That’s when I was experiencing the same kind of nasty exceptions that you describe above.

Experimentation revealed that the ‘receiveUpload’ event is fired, while the upload is started in a separate thread. Note that the upload goes ahead and starts trying to open the file, before even waiting for the ‘receiveUpload’ event to finish. So it may well start complaining about the file before the ‘receiveUpload’ event listener has had a chance to tell it not to bother. Moreover, the ‘interruptUpload’ request just sets a flag that the uploading thread will check at some point, but if you have returned null from ‘receiveUpload’, it may well attempt to write to the null OutputStream before realizing that it has been interrupted. That’s where the ugly exception comes in.

I got the exception to stop plaguing me by making sure I always returned a valid OutputStream from ‘receiveUpload’, even if I could tell from the MIME type that I didn’t want to receive the upload. Instead of returning null in my off-nominal cases, I would return a new ByteArrayOutputStream(). (And if you’re concerned about wasting the memory, you could use NullOutputStream from Apache Commons, or you could roll your own.)

Once I had done that, the lesser problem remaining was to sort out the various error messages that I would receive from ‘receiveUpload’, ‘uploadStarted’, and ‘uploadFailed’, to decide which was the one that was relevant to show the user, and which ones were cascading nonsense. (Note that because of the multithreaded implementation, the detection of the wrong MIME type in ‘receiveUpload’ might happen before or after an error reported ‘uploadStarted’. And you’ll get an ‘uploadFailed’ event that may well say ‘unknown error’, which should be ignored if you already expected to fail because you didn’t really want to start in the first place.)