Do your exceptions subclass Exception, or RuntimeException? Do you shout in frustration each time the compiler chokes because you forgot to add that try/catch, or do you thank it for reminding you to consider that case? Should more languages incorporate this feature, or should it be removed from Java altogether?

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

I like checked exceptions in very specific situations where I have written both ends of the interface. I like having the compiler ensure that I'm doing proper error checking in cases where I know that I should be doing error checking.

IOException and SQLException? They can go to hell. Especially SQLException -- it's the most useless exception ever.

I'm still in the static checking = mindset, so that part of me likes them.

I think a better solution would be:

A warning instead of an error if the exception specification was violated. (In general I think the Java compiler is *way* to freaking picky about things that should be warnings, like unreachable code.)

Have exceptions be checked only on public members. Infer the behavior of other methods.

Personally, I find them incredibly annoying to program with, but rather nice concept-wise. If an object reaches a point in it's code where it knows that "I'm fucked. Outside help is needed to overcome this" it's nice to tell the supervising code that "this object could potentially fail. Unless you want to crash as well, you better handle it somehow". If that is a critical server-application, it's better to yell at the compiler a little bit while writing than to have the server crash because of an uncaught ClientMonitorDoesntSupport32BitColourModeYouShouldSwitchTo16BitException.

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

What the world needs is optional exception-checking. And I don't mean -fno-checked-exceptions, I mean that each function has a separate toggle. You add the safety of exception safety, but you gain the flexibility of non-checked exceptions (for instance, a library writer might check the exceptions for the functions that are publicly visible, to make sure that no library-generated exceptions escape. Other functions wouldn't have to have checking).

coppro wrote:What the world needs is optional exception-checking. And I don't mean -fno-checked-exceptions, I mean that each function has a separate toggle. You add the safety of exception safety, but you gain the flexibility of non-checked exceptions (for instance, a library writer might check the exceptions for the functions that are publicly visible, to make sure that no library-generated exceptions escape. Other functions wouldn't have to have checking).

For checked exceptions, I sorta like the way C++ does it, where it's optional. But I'd rather have it so that it would figure out some sort of compile-time error there instead of what it does: something about throwing a different exception or calling unexpected(). (Not that this sort of checking would ever be possible to do in C++.)

C++ needs a "does not return" return value as well. I tire of writing assert(false).

Hangar wrote:For checked exceptions, I sorta like the way C++ does it, where it's optional. But I'd rather have it so that it would figure out some sort of compile-time error there instead of what it does: something about throwing a different exception or calling unexpected(). (Not that this sort of checking would ever be possible to do in C++.)

C++ needs a "does not return" return value as well. I tire of writing assert(false).

I was part of a discussion that suggested statically-typed exceptions for C++, and the conclusion was that it would definitely be possible, but only as far as functions for which you have definitions visible, or else declared exception specifications. The idea was to add a "throw (auto)" specification which allows a function (notably a templated function) to be specified to throw only that which it might acutally throw. IOW, it allows statically-checked exceptions to basically propagate through templates, in a wondrous system of convenience. The idea also suggested using "static throw (std::exception)" for statically-checked exceptions.

BTW, in C++, when an exception specification is violated, std::unexpected() is called. This calls std::terminate(), unless you have passed a function to std::set_unexpected, in which case this function is called. If it throws an exception, it is checked against the specification that was originally violated. If it matches, the exception continues propagation. If not, then std::bad_exception is checked against the specification. If it matches, then bad_exception is thrown. If not, terminate() gets called.

This can be useful, actually, because it can mutate foreign library exceptions into your own in one place, rather than at every instance in the code. It's really too bad MSVC doesn't support it.

I dislike checked exceptions. A checked exception is effectively part of the API you expose but which exception you throw is often an implementation detail so you lose some abstraction you could have. Even worse you can easily find yourself in a position where you cannot recover from an exception and the only reasonable thing to do is to pass it up to some general error case. That's ok if you control all the code in the project but leads to trouble when other people are using your code. If you add a new checked exception you've just changed the API they are trying to call and forced them to recompile everything to include the new exception. This is unreasonable so people usually just catch the checked exception and rethrow it as an unchecked exception, defeating the whole point of checked exceptions in the first place.

On the other hand checked exceptions are at least a nice way to force programmers to include some exception handling in cases where they really need to account for errors.

segmentation fault wrote:personally i dont use exceptions. i guess i still use the dinosaur that is return values.

I think that exceptions and return values should not be considered interchangeable. I can ignore a returned error code all I want while I have to deal with an exception somewhere. That and the exception at least tells me what went wrong while a return value often only indicates a failure without any hint of the type of failure or where it occurred.You can get away with it sometimes if you are returning an actual value and might return null if the method fails but if your method is "boolean saveData(File file)" then I can easily call it without ever considering or even saving the return value, completely ignoring any failures.I've even seen the opposite, and by far the worst, case; using exceptions in place of return values and extracting some result from the exception itself.

When exceptions are available, I don't believe return values should ever indicate any sort of error. Otherwise you get bugs because people ignore them. Anything which isn't fatal to the operation should log an error or silently work around, and fatal errors should throw.

If the client needs some service that may be silently disabled due to errors, it should be specifically requested by the client in the initial call (in which case it should throw if not available) or the client should have to query its availability before using it. If used when not available, it should be rendered a no-op, failed assertion or exception.

Micron wrote:I dislike checked exceptions. A checked exception is effectively part of the API you expose but which exception you throw is often an implementation detail so you lose some abstraction you could have.

Oh, I very much disagree with this. Exceptions that you can throw are a part of the API you expose, whether it's a checked function or not. You should no more be able to say "hey, I found a new exception I want to throw" than you should be able to decide to shuffle around the meaning of the arguments or return value. If you don't do that, besides "catch(...)" or "catch(Exception)", the callers can't do anything to keep errors from propagating up the chain.

The only exception to this is what subclass of a more generic exception you throw, and exception specifications don't bind you in that respect.

I think it's a mess either way. What I really want is a way to list the possible exceptions in the API without forcing the caller to handle all of them. I totally agree that a surprise mystery exception is useless to the caller but I keep running into cases where exceptions are thrown in a location where I can't reasonably recover from them. There has to be a better way where I can be aware of possible exceptions without having to explicitly rethrow them if I can't do anything about it.

Hangar wrote:If the client needs some service that may be silently disabled due to errors, it should be specifically requested by the client in the initial call (in which case it should throw if not available) or the client should have to query its availability before using it. If used when not available, it should be rendered a no-op, failed assertion or exception.

This is where checked exceptions come in handy. For example, I wrote a highscore list for a game about a week ago. If for some reason the list failed to initialize (due to a problem with the score file, or the data contained in the file), it would throw an exception. The rest of the program could work perfectly without this functionality, so I wanted the game to simply sever this functionality and continue on. Making the ScoreListException checked forced the game to do something about it, and change it's workings so it wouldn't make any calls to the score list. On the other hand, I made the InvalidScoreEntryException unchecked, because this would be thrown when a score entry with invalid values was being entered. Invalid values would indicate that the problem originated somewhere else; something had been lazy about checking it's invariants, or a coding error created malformed entries. This is a "please contact developer" exception, and not something the code itself should be expected to handle.

I think it's a mess either way. What I really want is a way to list the possible exceptions in the API without forcing the caller to handle all of them. I totally agree that a surprise mystery exception is useless to the caller but I keep running into cases where exceptions are thrown in a location where I can't reasonably recover from them. There has to be a better way where I can be aware of possible exceptions without having to explicitly rethrow them if I can't do anything about it.

Java has the @throws tag in it's docs.Also, if something throws a checked exception because, possibly, you might want to handle it, but you know you won't be able to in this case, and neither will any higher part of the program, you could always throw new RuntimeException(oldException);

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

Sure you can. The problem I see is that that is what people are doing all too frequently. I totally agree with your example of how the exceptions should be handled, I'd just rather not have to write any code except for the cases I actually want to try to recover from. Instead I have to catch any number of checked exceptions that can't be dealt with. Perhaps this is a just a problem with which exceptions developers have chosen to write as checked but in many cases I can not know if someone calling my method can recover from an exception so how should I know which are checked or not?

The "@throws" tag is all well and good but I shouldn't have to rely on a manual tag to find out what a method might throw. Just like I shouldn't have to look at a "@returns" tag to find out the return type. Rysto is right that you can include them in the throws list but then the distinction between checked and unchecked is not obvious and I have no way of knowing that the list is complete. Still its the best option in the language so I live with it.

btilly wrote:I find it interesting that Bruce Eckel, who knows something about Java has concluded that checked exceptions are a bad idea. And the reason is exactly that checked exceptions are so annoying that they encourage people to swallow exceptions, which is exactly what you really don't want to do.

Micron wrote:I think that exceptions and return values should not be considered interchangeable. I can ignore a returned error code all I want while I have to deal with an exception somewhere. That and the exception at least tells me what went wrong while a return value often only indicates a failure without any hint of the type of failure or where it occurred.

well if youre function call doesnt return a certain value designated as success (usually 0) it would be in your best interest to deal with it. in addition, depending on the return value or errno, you can know what went wrong.

Micron wrote:You can get away with it sometimes if you are returning an actual value and might return null if the method fails but if your method is "boolean saveData(File file)" then I can easily call it without ever considering or even saving the return value, completely ignoring any failures.

well whether its an exception or a return value, you have to prepare to receive it. i mean you can call saveData without a try and things will still get messy.

segmentation fault wrote:well whether its an exception or a return value, you have to prepare to receive it. i mean you can call saveData without a try and things will still get messy.

The thing is that if you don't check the return value things can silently go wrong. The save button could fail to do anything, yet not produce an error. On the other hand, an uncaught exception will make it blatantly obvious that you did something wrong, because the program will crash. (Or with checked exceptions, fail to compile in the first place!)

During testing, this is exactly what you want. Once you get into deployed systems things get a lot more hazy when it comes to which is the appropriate reaction. That said, you could wrap the whole thing in a "catch(...)" and save the current state to a file and exit; done right, this is probably better than silent failures.

You can have tools and such like Lint that will look for ignored return values, but there are enough cases where you just don't care that there is a LOT of noise. (Who really checks the return value of printf?)

Rysto wrote:Micro, how on earth do you expect the exception list to be guaranteed to be complete without checked exceptions? You're not making any sense here.

You're right. I'm complaining that I can't have it both ways at once. In fact I think that sort of thinking is what got us the messy combination of exceptions we see in Java which was my original complaint. Let me try to explain.

I think that both checked and unchecked exceptions are reasonable tools. (You might compare them to statically vs dynamically typed languages.) You can certainly make a system work with either one and you can probably argue that one or the other is a better tool for certain types of problems.With checked exceptions you know what types of exceptions to expect and can try to find ways to handle each of them gracefully. That's nice because you can make sure that you differentiate between types of errors; you might recover from some, ignore others, and halt the program in some cases. You also don't have to worry about any surprises, you know that no matter what goes wrong it will fall into any one of a specific set of possible exceptions. Unfortunately this also requires more code as you write catch blocks for each exception type, bad coding if you fall into the pattern of just catching "Exception", and messy APIs if you end up passing a dozen different exceptions up the call stack. The more exceptions you are asked to handle with each method call the less likely you will be able to deal with them individually and will instead fall back to "catch( Exception e )".With unchecked exceptions you don't have to stop to think about the exceptions as the default behavior is to effectively rethrow the exception and you don't have to add all those extra catch blocks or "throws" statements. Unfortunately this also means you can ignore errors you really should handle because there's nothing I can do to force you to think about a possible exception when you call one of my methods. I can document the exceptions I might throw but you can ignore them and you can't be certain that my method won't allow some undocumented exception type to propagate up from another block of code. Since you can't be certain of all the possible error cases you have to allow some exceptions past your catch blocks or include a general error case.

I can think of cases where I want to use either of these styles and I think my real complaint with Java is that it mixes them together. By including both types we get some of the benefits of each but also throw out many of their advantages. We get checked exceptions that force us to recognize some possible failure conditions but we always have to be prepared for an unchecked exception as well so we have to include a general error case even if we think we can recover from all possible exceptions. We get the freedom of unchecked exceptions which which can ignore in any area were we know attempting to recover would be useless but because we have checked exceptions as well we end up with a bunch of try-catch blocks which re-throw them as unchecked exceptions. That's extra code we have to write which gives absolutely no functional benefit.By mixing the two together we never get to take full advantage of either style and almost always have to do extra work. Given the choice I would much rather just have one or the other and of the two I think unchecked exceptions are the more reasonable approach. (How would you handle a NullPointerException as a checked exception? Include it everywhere or not at all?)

Thanks for finding Eckel's opinion btilly, his argument is certainly more convincing than mine.

EvanED defended my argument about return types perfectly. Handling an exception is enforced (at compile time for checked and at run time for unchecked) unless you deliberately catch and ignore it, in which case you deserve what happens. Return types can be silently ignored (you don't even need to assign them to a local variable) without warning. At least an empty catch block might skip dangerous statements in the try block following an exception.

Like most things in Java, the exception model is probably a good idea when youre doing large-scale enterprise development, but an irritant when youre just writing small-medium sized algorithms/programs.

That's the most annoying exception ever. That never happens unless I .interrupt() the thread myself manually, and even if I do, I pretty much always just want the program to continue normally anyway.Sure, you could write, say, a file download thread that sleep()s for a while while letting some buffer fill, then use interrupt() to stop that thread, but since when are exceptions supposed to be used for program flow anyway? If you REALLY need to know if the sleep was interrupted, just have it return a boolean. (kinda like how InputStream.read(byte[]) works)

Changing InterruptedException to a RuntimeException would be even worse, though, as it would work most of the time, but if you ever interrupt and don't catch, you'd kill the entire thread.

Not true. The point of exceptions is to let the programmer to decide what to do with exceptional conditions. Ignoring is one possible decision.

The way that I want to program is for me to not write code for exceptions, and then have them blow up with nice stack backtraces for debugging purposes. This is convenient and perfectly acceptable on applications for internal use. (Which is what I write.)

btilly wrote:Not true. The point of exceptions is to let the programmer to decide what to do with exceptional conditions. Ignoring is one possible decision.

Fine.

In the vast majority of cases, ignoring an exception is to completely defeat the purpose of having exceptions. There are rare cases where it's the correct response(InterruptedException being a good example), but usually swallowing exceptions in an awful coding practice.

Rysto wrote:In the vast majority of cases, ignoring an exception is to completely defeat the purpose of having exceptions.

If you're talking about swallowing the exception then I totally agree. However in Posi's example we had one case of silently swallowing the exception and one case of not handling it. If you don't handle the exception I think that's fine and does not defeat the point of having exceptions. The program should terminate which might be a sign of a lazy programmer but at least it terminates with an exception giving some hint as to where it all went wrong. I would much rather see that than have a program silently ignore exceptions and try to continue.

Rysto wrote:In the vast majority of cases, ignoring an exception is to completely defeat the purpose of having exceptions.

If you're talking about swallowing the exception then I totally agree. However in Posi's example we had one case of silently swallowing the exception and one case of not handling it. If you don't handle the exception I think that's fine and does not defeat the point of having exceptions. The program should terminate which might be a sign of a lazy programmer but at least it terminates with an exception giving some hint as to where it all went wrong. I would much rather see that than have a program silently ignore exceptions and try to continue.

Lazy perhaps, but lazy like a fox.

The "right" way to handle errors depends on what you're working with. Dumping core in a consumer application is startling to the user. You really want to catch and deal with exceptions as close to the error as possible, preferably after logging the problem. Giving a stack backtrace in errors shown on a public-facing website is a security hole. (It lets attackers debug their attacks on your website - see SQL injection attacks for an example of why this is a bad thing.) It is much better to log the error somewhere and show a bland error page. But in an internal-facing website, showing the stack backtrace is both the simplest and most useful thing to do with a random exception.

In any case, in many applications there is a reasonable default thing to do that makes sense most of the time. Doing that default should be as easy as possible. But checked exceptions in Java makes that difficult and annoying to do. Which means that checked exceptions are usually a bad idea.