On Tue, 14 Jan 2003 20:56:49 -0500 (EST), [EMAIL PROTECTED] wrote:
Hey Dan:
>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...
True, but that wasn't exactly what I was getting at. I was
thinking more along the lines of a developer looking at a
programatically correct try statement that had a potentially
generically named (albeit not necessarily technically ambiguous to the
compiler) exception being caught at the bottom. If you are looking at
a try statement that you didn't write that has 15 - 20 method calls in
it, some of which are Java USB and some of which are from other APIs
(java.io, javax.comm, whatever) and at the bottom we're catching a
"NotOpenException", as a developer I'd have to go and lookup all of the
JavaDoc different methods being called to try to determine which API
set this exception was coming from.
Now if I'm unexperienced with a given API, I'll probably have
to do this anyways -- but by having "Usb" in front of all of the
exception names, at least as a neophite developer I'd be able to
specifically target which object/class method calls could generate this
method.
One issue I have with some Java code is that some people will
put a ton of code into one big try statement, instead of breaking
things up. Sometimes this is somewhat logical, but as there is no
visible mechanism to determine (by looking at just the code) which
methods generate which exceptions can sometimes require tracing and
searching to find the source of the exception. Some exceptions are
easier to determine their origin than others -- for example, you'd
expect an ArrayIndexOutOfBounds to be caused by an array access. But
if you're not familiar with the API, a "NotOpenException" is a bit more
ambiguous. What isn't open: A stream? A file? A socket? A USB
endpoint?
>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:
Ah, I see. In that case, adding the "Usb" prefix to the other
classes does make added sense, as would leaving "UsbException" as-is.
>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.
Well, don't count on people not wanting to catch
RuntimeExceptions :) . I have a number of places in my project (the
jSyncManager -- http://www.jsyncmanager.org, which does need a good
solid Java USB API :) ) where I'm catching Throwable and
RuntimeException. Some of these are so that we can grab a copy of the
stack trace and write them to the user log, others are because we try
some tests expecting some potentially serious errors to see what's
available to us (the code handles a full Palm HotSync-compatible
protocol stack and set of synchronization tools completely in Java, and
as there are various physical layers upon in which you can synchronize
the Palm (USB, serial, modem, IR, network, Bluetooth (eventually...)),
we will try to load the classes for the underlying Java APIs to access
each of these resources, and catch resultant RuntimeErrors and other
Throwables as a way to tell our code "Okay, this transport type isn't
available -- don't offer it as an option to the user").
Brad BARCLAY
=-=-=-=-=-=-=-=-=
>From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
E-Mail: [EMAIL PROTECTED] Web: http://www.jsyncmanager.org
-------------------------------------------------------
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
