Prev: how to kill a java thread by force?
Next: X11 based GUI toolkit for java on unix AND windows
From: markspace on 14 Dec 2009 14:47
Leif Roar Moldskred wrote:

> Then, give us some way to handle more than one type of exception in the
> same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
> or, hell, why not re-use the switch syntax?


It's now likely something like this will show up in Java 7

<http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html>
From: Eric Sosman on 14 Dec 2009 18:32
On 12/14/2009 2:22 PM, Leif Roar Moldskred wrote:
> [...]
> Then, give us some way to handle more than one type of exception in the
> same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
> or, hell, why not re-use the switch syntax?
> catch( IOException ex ) {
> case FileNotFoundException: logFileNotFound( ); break;
> case EOFException: logUnexpectedEof( ); break;
> default: logOtherIOError( );
> }
> catch( Exception ex ) {
> case FooException:
> case BarException: logFooBarError( ); break;
> case WeirdException: logWeirdError( ); break;
> default: logBadThingHappened( ); throw ex as unchecked;
> } // end catch( )

The value of this escapes me. It seems you're not suggesting
a new capability, but just a new syntax for an existing capability:

catch (FileNotFoundException ex) {
logFileNotFound();
} catch (EOFException ex) {
logUnexpectedEof();
} catch (IOException ex) {
logOtherIOError();
} catch (FooException ex) {
logFooBarError();
} catch (BarException ex) {
logFooBarError();
} catch (WeirdException ex) {
logWeirdError();
} catch (Exception ex) {
logBadThingHappened();
}

All you've saved is one call to logFooBarError -- or have I
missed something?

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
From: Arne Vajhøj on 14 Dec 2009 20:37
On 14-12-2009 14:22, Leif Roar Moldskred wrote:
> I'd like to see the "checkedness" of exceptions be separated from the
> class hierarchy of Throwables and instead be declared when you throw the
> exception. After all, whether or not an error should cause a checked or
> unchecked exception depends more on where in the code it occurs than on
> what the error is: there is no reason why an IllegalArgumentException from
> input validating code should be unchecked, as the cliend code of that
> _should_ know how to deal with that exception. On the other hand, if the
> IllegalArgumentException occurs deep down in the business logic where it's
> assumed that the data has all been validated and is clean, it makes sense
> to throw it as unchecked: none of the immediate code would have any idea
> what to do anyway.
>
> "throw new FooException( "Bad thing happened" ) as unchecked" or
something
> in those veins.

I don't like the idea of having throwchecked and throwunchecked. It
could become very messy with the same exception being both.

I seems quite fair to me that the type carry the information whether
it is checked or not. If necessary just create two types.

I don't like the extends RuntimeException => unchecked either. @Checked
and @Unchecked would be much nicer. But annotations did not exist back
then. And now it is too late.

> To prevent lazy programming, let us add the rule that a method also have
> to declare all unchecked exceptions which are thrown _directly_ from
> within that method (i.e. thrown by an explicit throw statement in the
> method body.)

Does not make sense to me.

> Next, give us an implicit, method-level try block: allow us to have the
> method block be followed by catch blocks and a finally block:
>
> public void myMethod( ) throws MyException {
> ...
> } // end myMethod( )
> catch( FooException ex ) {
> throw new MyException( ex );
> }
> finally {
> System.out.println( "myMethod exited." );
> }

Does not make sense to me. The code could just as well be inside
the method.

> Then, give us some way to handle more than one type of exception in the
> same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"

That has been proposed before. I guess it is OK.

> or, hell, why not re-use the switch syntax?
> catch( IOException ex ) {
> case FileNotFoundException: logFileNotFound( ); break;
> case EOFException: logUnexpectedEof( ); break;
> default: logOtherIOError( );
> }
> catch( Exception ex ) {
> case FooException:
> case BarException: logFooBarError( ); break;
> case WeirdException: logWeirdError( ); break;
> default: logBadThingHappened( ); throw ex as unchecked;
> } // end catch( )

Test on type is an anti-OO thing.

Arne

From: Arne Vajhøj on 14 Dec 2009 20:38
On 14-12-2009 09:48, Joshua Cranmer wrote:
> On 12/14/2009 05:46 AM, Arved Sandstrom wrote:
>> For the purposes of these "next language" discussions I consider C# to
>> be a near-Java. Although personally I do prefer C#.
>
> Considering that my first introduction to C# was as the language of
> choice for a programming project due in a fortnight, I much prefer Java.
> Especially Swing.

For GUI then C# is easier.

Arne

From: Roedy Green on 14 Dec 2009 22:24
On Mon, 14 Dec 2009 10:46:31 GMT, Arved Sandstrom
<dcest61(a)hotmail.com> wrote, quoted or indirectly quoted someone who
said :

>I'll probably write a new blog "Stupid New Language
>Blogs are Considered Evil." :-)

Java is not the final language. If you don't participate in
discussions of what is successor should be like, you can't very well
complain at the flaws of its successor. It is a bit like voting.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The future has already happened, it just isn�t evenly distributed.
~ William Gibson (born: 1948-03-17 age: 61)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: how to kill a java thread by force?
Next: X11 based GUI toolkit for java on unix AND windows