Hacker News Reader

Comment by bad_user | Hacker News Reader

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

At least Java 7 has multi-catch, i.e.

  catch (FirstException | SecondException ex)

I think checked exceptions are just ahead of their time. They make sense when you statically check your code against contracts, which is why they showed up again in the spec# research project. http://en.wikipedia.org/wiki/Spec_Sharp

Optional checked exceptions have some benefits.

Java got them the wrong way around - unchecked should have been the default, with checked available when you need them.

Because Java does them the other way around, you either get code bloat from the large numbers of exceptions you are catching and handling subtly differently or you have a generic catch(Exception e){..} block. Neither are ideal.

exactly right. I'm always surprised more people don't land here when this debate comes up.

Why are you opposed to checked exceptions?

Frankly this is one complaint about java I have never understood. I, myself, have missed checked exceptions in C# when I have had to port Java code to C#.

Getting rid of something is always harder than adding it later.

I don't think this is the case here. The question isn't whether you "add" or "remove" something. The question is whether the old programs will still work or not.

If I understand checked exceptions correctly, removing them will only allow more programs to compile. The old ones will still be valid as their (now optional) try-catch/finally blocks won't go anywhere.

throws RuntimeException and try / catch around RuntimeException would still be valid, so I can't see how changing all checked exceptions to runtime shouldn't affect the flow of the code.

If users wanted to they could declare 'throws TheirParticularRuntime' all the way up the stack and it would work like checked exceptions, right?

Some people like them, you know.

Can you expand on why would you like to get rid of checked exceptions?

It often leads people to write code like this:

    try {
        // do stuff
    } catch (TheCheckedException ex) {
        // ignore it
    }

then the code continues even though it could be in a bad state if an exception did occur.

It's a much better solution to let it propagate up the call stack until it can be dealt with appropriately (e.g. by ending the application, giving a 503 error on a web page request, etc.) Unchecked exceptions will propagate up the call stack by default if you don't do anything, making it harder for people to write bad exception handling code.

So add a 'throws' clause to the method in which you call the code that throws the checked exception and it will propagate upward.

...or rethrow it as an unchecked exception(RuntimeException).

Yes, this! The most irritating debugging I've had to do in Java code is when someone catches an exception, but fails to handle it effectively, resulting in another exception being thrown later. If you don't know how to handle it effectively, just add the 'throws' clause. It's less typing than try/catch, so I don't understand why people choose to make extra work for themselves and for me.

I see a lot of comments here that seem to assume catching the exception is the only option.

Exactly. In Eclipse it's so ridiculously easy to make the method pass it on by adding the throw to your method. I find checked exceptions really useful every day :)

I like checked exceptions because you can't not deal with the error condition. Swallowed exceptions is a code smell that any half-decent developer will notice, whereas failing to check for some return value is much more subtle. Java allows you to have both, since you can design your exceptions as unchecked, or rethrow a checked exception wrapped in a runtime exception.

Well, just use runtime exceptions for your own code. (Though, they'll hardly ever change the exceptions in the base libraries to runtime exceptions)

They tend to force you to handle an exception at the wrong level. If you handle them correctly you still have to catch and wrap them at a low-level to not leak an implementation detail in methods signatures. IDE tend to be overly specific on the type of exceptions a method can rise when autofixing methods decls.

In the end you write boilerplate and fight the IDE.

Because a huge proportion of the time there's nothing useful that you can actually do when you catch an exception, other than print the stack trace and exit. And because people are forced to catch the exception instead of letting it bubble up and stop the program, half the time they just swallow it and ignore it, which is even worse.

A decent roundup of some of the arguments for and against: http://www.ibm.com/developerworks/java/library/j-jtp05254/in...

Reply on news.ycombinator.com