You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Henri Yandell <ba...@generationjava.com> on 2004/10/29 19:35:04 UTC
Exception handling Was: Future JDK features 2 items
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) {
}
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by sebb <se...@gmail.com>.
On Fri, 29 Oct 2004 13:35:04 -0400 (EDT), Henri Yandell
<ba...@generationjava.com> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by Felipe Leme <ja...@felipeal.net>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 19 Nov 2004 23:31:11 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Fri, 19 Nov 2004 23:21:02 -0800, Daniel Rall <dl...@collab.net> 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?
That might catch all the exceptions I am expecting, but it will also
catch any exceptions that I am not expecting. Thus the behaviour I
code into the catch clause here might be totally inappropriate for
some of the exceptions it ends up catching.
Also, the compiler will not help me discover that the methods that I
am calling have changed the exceptions that they throw, meaning that
the catch clause is even more likely to become inappropriate over
time.
Finally, I have now lost the self-documenting characteristics of
explicitly naming the exception types I am catching.
At my current company, and at my last company, we have coding
guidelines that explicitly ban the use of what you suggest, for the
reasons above.
Having had the ability to do (the first of) what Henri suggests in
other programming languages in the past, I would be very much +1 on
that inclusion in Java. :-)
--
Martin Cooper
>
> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Exception handling Was: Future JDK features 2 items
Posted by RK <ra...@imisoft.com>.
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:brett.porter@gmail.com]
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 <no...@devtech.com>
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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by Brett Porter <br...@gmail.com>.
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 <no...@devtech.com> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Exception handling Was: Future JDK features 2 items
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > > 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by Rainer Klute <kl...@rainer-klute.de>.
Am Sa, 2004-11-20 um 08.31 schrieb Craig McClanahan:
> On Fri, 19 Nov 2004 23:21:02 -0800, Daniel Rall <dl...@collab.net> 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: klute@rainer-klute.de
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 19 Nov 2004 23:21:02 -0800, Daniel Rall <dl...@collab.net> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by Daniel Rall <dl...@collab.net>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Exception handling Was: Future JDK features 2 items
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
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
hps@intermeta.de +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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org