Originally (before final approval) it wasn't declared anywhere, since it can be thrown in a very large number of places. Only RuntimeExceptions can be thrown without being declared. Now, it is declared in all places that it can be thrown, so it could be a normal Excpetion (UsbException). Part of the thinking was it reflects an exception that has occured independent of any programming error, but in hindsight that's not a good reason, as disconnects are inevitable and all USB apps have to be prepared for them to happen.
Probably in the next rev of the API it should change...unfortunately, that would be a non-backwards compatible change, since programs that previously didn't catch it would not compile... Why don't you open a bug or feature request for that? On Sat, 31 Dec 2005, Elliotte Harold wrote: >I'm curious. What's the reasoning behind making UsbDisconnectedException >a runtime exception? A disconnected device on the bus is an >environmental condition that cannot be predicted or tested for in >advance. It does not indicate a programming error. This seems like >exactly the place for a checked exception. Why is this one exception >pulled out as a runtime exception when most UsbExceptions are checked? >What am I not seeing here? > > -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ javax-usb-devel mailing list javax-usb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
