004 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 y
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 brevit
> > > 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 w
On Fri, 19 Nov 2004 23:31:11 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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 blo
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
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 {
> > >
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) {
>
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 | RemoteExcept
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
> 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 P
gt; 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 {
>
&
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
> > pe
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 the
On Oct 27, 2004, at 4:15 PM, Bernhard Fastenrath wrote:
method pointers? closures?
Is anybody going to suggest self-modifying java assembler code as a
language feature?
I don't really see how you got from method pointers and closures to
self-modifying code (I see that as a bit of fear mongering).
Dain wrote:
> I understand what you are saying, but do you believe that Sun could
> actually get such a feature right?
I take your point, and tend to think not. I don't believe that Sun would
get it right first time, not if we consider their track record.
> So, yes, I am arguing that no feature
method pointers? closures?
Is anybody going to suggest self-modifying java assembler code as a
language feature?
Is the goal to break Java and render it useless?
In my opinion we can live without closures.
You didn't have to attach "for a bit longer".
Jim Moore wrote:
The way that most modern lan
PROTECTED]
Sent: Wednesday, October 27, 2004 12:53 PM
To: Jakarta General List
Subject: Re: Future JDK features 2 items
On Oct 27, 2004, at 1:10 AM, Danny Angus wrote:
>
> Dain wrote:
>
>> If you want method pointers today, just get a good byte code
>> generation tool.
>
On Oct 27, 2004, at 1:10 AM, Danny Angus wrote:
Dain wrote:
If you want method pointers today, just get a good byte code
generation
tool.
Yeah I know, and I seriously believe that workarounds such as this do
more
to harm the so-called "purity" of Java than providing explicit language
level mechan
Dain wrote:
> If you want method pointers today, just get a good byte code generation
> tool.
Yeah I know, and I seriously believe that workarounds such as this do more
to harm the so-called "purity" of Java than providing explicit language
level mechanisms for method pointers.
The AWT moved fr
>> Where's the advantage of a method pointer?
> Maybe Mr. Angus wasn't going here, but behind my
> concept was work I have done in C/C++ with arrays
> of function-through-pointer for varied functionality
> depending on context.
Yes. It was in order to provide much more dynamic variation in behavi
On Oct 26, 2004, at 1:17 AM, Danny Angus wrote:
1/ Ok don't flame me... "Method pointers"
If you want method pointers today, just get a good byte code generation
tool. We use cglib in Geronimo to generate FastMethod objects, which
look a lot like reflection Method but are about a 100 times faste
> [Original Message]
> From: Bernhard Fastenrath <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Date: 10/26/04 2:09:02 PM
> Subject: Re: FW: RE: Future JDK features 2 items
>
> Dan Lydick wrote:
>
> >> <>From: Danny An
Dan Lydick wrote:
<>From: Danny Angus <[EMAIL PROTECTED]>
1/ Ok don't flame me... "Method pointers"
But still, be sure to watch for flames from the
Purist Society! They _do_ have a point, ya know.
I *know* it is possible to accomplish all the delegation one might want by
using polymo
> [Original Message]
> From: Danny Angus <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Date: 10/26/04 3:17:32 AM
> Subject: Future JDK features 2 items
>
>
> 1/ Ok don't flame me... "Method pointers"
But still, be sure
1/ Ok don't flame me... "Method pointers"
I *know* it is possible to accomplish all the delegation one might want by
using polymorphism, but this often leads to unncessary screeds of
boiler-plate,
so I still I believe there is a case for some kind of streamlining of
delegation by allowing it to b
25 matches
Mail list logo
