Issue Details (XML | Word | Printable)

Key: FILEUPLOAD-70
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: David Graham
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Commons FileUpload

DefaultFileItem should not catch Exception

Created: 24/Mar/03 01:03 PM   Updated: 09/Mar/07 08:32 PM
Return to search
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Patch.txt 2003-04-14 11:53 PM Mohan Kishore 4 kB
Text File Patch.txt 2003-04-14 11:06 PM Mohan Kishore 3 kB
Environment:
Operating System: other
Platform: Other

Bugzilla Id: 18265


 Description  « Hide
There are several places in DefaultFileItem that catch Exception instead of the
specific exceptions thrown by the surrounded code. A better approach would be
to catch the specific exceptions (which I suspect will be IOException).

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mohan Kishore added a comment - 14/Apr/03 11:06 PM
Created an attachment (id=5823)
Minor exception-handling changes

David Graham added a comment - 14/Apr/03 11:11 PM
The proposed patch swallows IOExceptions in a "catch (Exception)" block. The
IOException should propagate out of the method.

Mohan Kishore added a comment - 14/Apr/03 11:27 PM
Any particular one in mind or all of them? Am swallowing all exceptions for the
xxx.close() methods. Otherwise, these may hide other more relevant exceptions.
Alternative might be something like this:

IOException ex = null;
try {
fout = new FileOutputStream(file);
fout.write(get());
} catch (IOException ioe) {
ex = ioe;
} finally {
try { if (fout != null) fout.close(); } catch (IOException ioe) { if (ex != null) ex = ioe; }
}
if (ex != null) throw ex;


David Graham added a comment - 14/Apr/03 11:30 PM
There should be no "catch Exception" blocks. Just let any IOException propagate
out of the method. An exception thrown during close() will not hide any other
exception because they would have been thrown first anyways.

Mohan Kishore added a comment - 14/Apr/03 11:53 PM
i think i see what you are saying.. am attaching a patch without all those
finally clauses. Have left in one IOexception swallowing block in the get()
method, which would necessiate changing the multiple public method
signatures... Other changes are backwards compatible.

Mohan Kishore added a comment - 14/Apr/03 11:53 PM
Created an attachment (id=5824)
Removed the finally clauses for close() methods

Martin Cooper added a comment - 28/Apr/03 07:07 AM
Fixed in the 20030428 nightly build.