RE: Exception handling Was: Future JDK features 2 items
Can't we handle in this
try {
}catch (Exception e) {
if( e instantceof JMSException ||
e instantceof RemoteException ||
e instance of SQLException){
...
}
}
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 21, 2004 4:26 AM
To: Jakarta General List
Subject: 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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]
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: 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]
Re: Exception handling Was: Future JDK features 2 items
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
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) {
...
}
If you really want to treat different types of exceptions differently,
you can special case by putting specialized catch blocks for the
special cases in front of this. The predominant use case, though,
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.
Sheesh, hasn't anyone ever heard of inheritance around here? :-)
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
On Fri, 2004-10-29 at 19:35, Henri Yandell wrote:
2/
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) {
}
+a bazillion. I like the first one better, though.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
On Fri, 29 Oct 2004 13:35:04 -0400 (EDT), Henri Yandell
[EMAIL PROTECTED] wrote:
On Fri, 29 Oct 2004, Dain Sundstrom wrote:
I actually love closures, and think it would be a great addition to Java. I
spend a lot of time tracking down poorly written try/finally blocks in
people's code where they don't properly close DB connections, IO streams, Jar
files, and even delete their temp files. A good closure library would
virtually eliminate this type of programming errors.
1/
How about the Perl6 finally system where you can attach a try/catch to
variables?
In Perl 6 it's:
my $p = P.new; POST { $p and $p.Done; }
or
my $p is post { .Done } = P.new;
So in Java it could be something like:
Connection conn = ds.getConnection(); finally(conn) { conn.close(); };
Connection conn = ds.getConnection() @ { conn.close(); };
Connection conn = ds.getConnection(); conn @ finally { conn.close(); };
Biggest problem is that I can't see a way to write that nicely.
2/
How about just being able to do multiple Exceptions in one block?
try {
} catch(JMSException, RemoteException, SQLException e) {
}
+1 That could save a lot of tedious repetition
or possibly even:
try {
} catch( (JMSException | RemoteException | SQLException) e) {
}
The last one is interesting as it could be a larger concept allowing
mixed-types; but from a finite set. Probably lots wrong with that idea :)
-
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]
FW: RE: Exception handling Was: Future JDK features 2 items
A definite +1 for multiple exceptions in a catch{} block.
I have had a number of times I have wanted to do this,
but have had to create a private method and refer all
catch{} blocks to it.
Dan Lydick
[Original Message]
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Date: 10/29/04 12:38:48 PM
Subject: Exception handling Was: Future JDK features 2 items
2/
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) {
}
The last one is interesting as it could be a larger concept allowing
mixed-types; but from a finite set. Probably lots wrong with that idea :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exception handling Was: Future JDK features 2 items
try {
} catch(JMSException, RemoteException, SQLException e) {
}
+1
(We used to have something like that in Smalltalk)
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
