Re: Exception handling Was: Future JDK features 2 items
Am Sa, 2004-11-20 um 08.31 schrieb Craig McClanahan:
On Fri, 19 Nov 2004 23:21:02 -0800, Daniel Rall [EMAIL PROTECTED] wrote:
On Fri, 2004-10-29 at 13:35 -0400, Henri Yandell wrote:
...
How about just being able to do multiple Exceptions in one block?
try {
} catch(JMSException, RemoteException, SQLException e) {
}
or possibly even:
try {
} catch( (JMSException | RemoteException | SQLException) e) {
}
Something like this would be truly excellent. I'm so sick of having to
write 30 lines of exception handling code.
How about two lines, which you can already do today?
try {
...
} catch (Exception e) {
...
}
Craig,
I wouldn't have expected that answer from you. :-)
Usually you don't want to just catch all exceptions in a single block.
Instead you want to have clusters of exceptions like in the example
quoted above, and you want to handle each cluster of exceptions
differently.
And often the exception types you'd like to cluster don't have a
sensible inheritance relation other than that they subclass from
Exception.
Yes, we do need another catching syntax between the two extremes catch
everything in one and catch each exception type separately.
Best regards
Rainer Klute
Rainer Klute IT-Consulting GmbH
Dipl.-Inform.
Rainer Klute E-Mail: [EMAIL PROTECTED]
Körner Grund 24 Telefon: +49 172 2324824
D-44143 Dortmund Telefax: +49 231 5349423
Softwarepatente verhindern: http://www.nosoftwarepatents.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
apcvs-unix-group
Hi all, could somebody add me to apcvs-unix-group? my account is matzew I would like to update the website for MyFaces, which is in incubator. Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
On Sat, 2004-11-20 at 05:31, Craig McClanahan wrote:
How about two lines, which you can already do today?
try {
...
} catch (Exception e) {
...
}
The problem with such approach is that it catches all exception, checked
or not (see below)
seems to be a standarized log it and exit or log it and rethrow it
in a wrapper exception strategy, which you can deal with quite
easily.
That makes sense for checked exceptions. For instance, when you use
reflection to invoke a method, you have to handle 2 or 3 checked
exceptions, which you typically want to just log and exit as you
described. But if you use a generic catch( Exception e ), you would
catch unchecked exception as well (like NullPointerException).
Sheesh, hasn't anyone ever heard of inheritance around here? :-)
Ask the java.lang folks :-)
I mean, there is a good 'inheritance chain' of
Throwable - Exception - RuntimeException - TheException
for unchecked exceptions, but for checked exceptions is just
Throwable - Exception - TheException ;
I think there is a missing class there. If we had something like this:
Throwable - Exception - UncheckedException - RuntimeException
Throwable - Exception - CheckedException
Or even just:
Throwable - Exception - RuntimeException
Throwable - Exception - CheckedException
Then your idea would make sense: we could just use the CheckedException,
without the need for changing the language sintaxe (just the API and
maybe some internal structures in the VM).
-- Felipe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: apcvs-unix-group
I imagine this request needs to goto infrastructure, though it seems to me that needing apcvs implies that maybe the incubator site is being automatically updated periodically. Especially as there's an incubator and incubator-site group too. So probably an email to the incubator list to ask how how things work for thei site might be a better idea than infrastructure. Hen On Sat, 20 Nov 2004, Matthias Wessendorf wrote: Hi all, could somebody add me to apcvs-unix-group? my account is matzew I would like to update the website for MyFaces, which is in incubator. Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
I'm in favour of the multiple exception catch. I think the common use
for this is to catch a series of checked exceptions in a certain way,
while avoiding catching unchecked exceptions which you want to
propogate.
This is a good thing, because often I've seen code that catches
Exception for brevity because it's considered to not be able to throw
anything else, and later a NullPointer crops up and gets swallowed by
the wrong handler, or a new checked exception gets introduced that is
also caught where different handling may have been appropriate.
As far as the common interface, I have no problem with the exception
in this case being a Throwable. I think the JVM assigning the greatest
common denominator base-class might be a little too much magic. And
as syntax is pretty crowded when you can do that in a cast in the
handler. But a lot of handlers are logging or wrapping in a new
exception so the type is irrelevant.
Cheers,
Brett
On Sat, 20 Nov 2004 14:45:37 -0500, Noel J. Bergman [EMAIL PROTECTED] wrote:
try {
} catch( (JMSException | RemoteException | SQLException) e) {
}
try {
...
} catch (Exception e) {
...
}
Usually you don't want to just catch all exceptions in a single block.
Instead you want to have clusters of exceptions
And what is the common interface for those exceptions? Exception? ;-) Are
you looking for catch (TypeList As ParentType), and just want the JVM to
exclude out other types derived from ParentType?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
