On Tue, 14 Jan 2003, Brad BARCLAY wrote:

>On Tue, 14 Jan 2003 19:13:44 -0500 (EST), [EMAIL PROTECTED] wrote:
>
>Hey Dan:
>
>>perhaps all exceptions in javax.usb should be prefixed with 'Usb'...
>
>       That's not such a bad idea.  If a developer is working with
>another developers code, it can help them to better understand where
>the exceptions being caught are coming from, particularily if you'r
>intermixing a bunch of calls in a single try statement that use both
>javax.usb and java.io (or some other API set).  If a try statement
>contains 15 - 20 statements, and there is a catch clause at the bottom
>for "NotOpenException", it isn't immediately obvious wether it's a
>javax.usb exception, some specialized stream exception, a Java Comm API
>exception

technically, javac will complain about an 'ambiguous class' and won't 
compile (which makes sense), but you're right that still we should keep 
the namespace in mind...

>(someone could in theory write a piece of code that takes
>input from a USB endpoint and retransmits it to a serial port, I
>suppose :) ), etc.  Prefixing the exceptions with "Usb" makes it
>immediately obvious when you see the catch clause which methods you
>should look at as to which ones throw this exception (obviously I'm
>presuming that someone would be modifying existing working code, as one
>would assume if they're trying to track down an actual occurance of a
>thrown exception that they'd have a full stack trace available to them
>pointing to the culprit).
>
>       The one issue I'd see with doing this is that the naming of
>"UsbException" is now perhaps a bit too generic.  As I understand it,
>this exception is intended for things that are specifically USB errors,
>as opposed to programming logic errors (like trying to read data from
>an endpoint before it's been opened).  If all the other classes have
>the "Usb" prefix, some people might mistake "UsbException" to be the
>parent class to all other exceptions, or may not understand that the
>exceptions it represents are actually hardware-level excptions.  I
>suppose this issue is more minor (as you do at some point have to
>assume the developer knows at least a bit about what they're doing),
>but a less (seemingly) generic classname for this exception may be
>useful if all the other exceptions have a "Usb" prefix.

Actually, UsbException is intended to be a rather generic USB-type 
exception, with other exceptions extending it where appropriate.  In 
almost all cases, a UsbException indicates problems on the actual USB bus 
(or relating to actual USB communication).  The idea is, the user can 
catch UsbException and that will cover all USB communication problems.  
If they want to get specific, they can also catch the specific subclasses 
(which are TODOs...), like UsbPlatformException, or 
UsbNoBandwithException, or UsbStalledException, or something similar, and 
then handle that specific problem (if possible).  For example:

try {
  pipe.syncSubmit(data);
} catch ( UsbStalledException usE ) {
  resetPipe();
  return RETRY;
} catch ( UsbNoBandwidthException unbE ) {
  closeSomeOtherPipes();
  return RETRY;
} catch ( UsbException uE ) {
  System.out.println("Problem while submitting : " + uE.getMessage());
}


but, since all the specific exceptions are subclasses of UsbException, if 
you don't care about the specific ones just catch UsbException and you're 
set.  However, if you catch a UsbException, the only way to tell what went 
wrong is read the string (which is hard to do programatically ;) 

As far as NotActiveException and NotOpenException, both those are 
RuntimeExceptions, so you don't need to catch them, as long as you're 
confident that you're not doing something wrong; they should only be 
thrown if you're trying to use an inactive config/interface or unopened 
pipe.


-- 
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: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
_______________________________________________
javax-usb-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel

Reply via email to