Post #118,548
9/23/03 10:01:38 AM
|
Checked Exceptions, Good or Bad
The serverside.com has an interesting discussion about the value of checked exceptions [link|http://www.theserverside.com/home/thread.jsp?thread_id=21538&article_count=16|James Gosling Chimes In on Checked Exceptions]
I have found that checked exceptions are a pain and if you have a good set of tests deliver little or no value. Gosling's example with the file not found would be discovered by unit tests very quickly. Whenever I prototype something, write a small utility or just try to learn a new API, checked exceptions pop up and annoy me. Bruce Eckel put it best [link|http://www.mindview.net/Etc/Discussions/CheckedExceptions|Does Java need Checked Exceptions?]
"The theory is that if the compiler forces the programmer to either handle the exception or pass it on in an exception specification, then the programmer's attention will always be brought back to the possibility of errors and they will thus properly take care of them. I think the problem is that this is an untested assumption we're making as language designers that falls into the field of psychology. My theory is that when someone is trying to do something and you are constantly prodding them with annoyances, they will use the quickest device available to make those annoyances go away so they can get their thing done, perhaps assuming they'll go back and take out the device later. I discovered I had done this in the first edition of Thinking in Java:
...
} catch (SomeKindOfException e) {}
And then more or less forgot it until the rewrite. How many people thought this was a good example and followed it? I began seeing the same kind of code, and realized people were stubbing out exceptions and then they were disappearing. The overhead of checked exceptions was having the opposite effect of what was intended, something that can happen when you experiment (and I now believe that checked exceptions were an experiment based on what someone thought was a good idea, and which I believed was a good idea until recently).
When I started using Python, all the exceptions appeared, none were accidentally "disappeared." If you want to catch an exception, you can, but you aren't forced to write reams of code all the time just to be passing the exceptions around. They go up to where you want to catch them, or they go all the way out if you forget (and thus they remind you) but they don't vanish, which is the worst of all possible cases. I now believe that checked exceptions encourage people to make them vanish. Plus they make much less readable code. "
|
Post #118,549
9/23/03 10:33:37 AM
|
Agreed, for the most part.
I'd like to be able to tell the compiler to enforce them or not. There are times when I find that having them forced upon me helps me remember what might be thrown there.
Using {} is a bad idea whether you are trying to save time or not. Most of the time what I do is create a generic exception for the application (or sub-application) that takes a Throwable as an argument. Every method throws the generic app exception, so I can just toss exceptions up the stack with a simple explanation. The generic app exception (or at least the common base class I use for them) prints the stack trace of the encompassed exception along with its own, so I just print them out in a common error handling routine. This seems to give me the best combination of error handling and convenience in Java, at least.
The other problem with Java exception handling is that there is a whole class of exceptions that don't require handling, so the whole mechanism is subverted. I've seen people subclass RuntimeException for the express purpose of not having to declare exceptions in the method signature.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #118,592
9/23/03 12:58:03 PM
|
Checked Exceptions: A Failed Experiment
Checked exceptions are an experiment in language design that unfortunately didn't pan out. They sound good on paper, but in practice cause far more pain that they are worth.
Most of Goslings argument for checked exceptions are really arguments for exceptions, not necessarily checked ones.
[an aside] ... Scott, your last two sentences seem to imply that RuntimeExceptions should not be handled (e.g. caught). It was my impression that it is the Error hierarchy that should not be caught. The Runtime hierarchy are unchecked because they contain exceptions that could happen anywhere (e.g. NullPointerException), so making them checked would mean nearly every method would have to declare them.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #118,593
9/23/03 1:41:06 PM
|
Re: Checked Exceptions: A Failed Experiment
My point was that people abuse the nature of RuntimeExceptions in order to avoid having to declare anything, so you end up with code that doesn't use checked exceptions when it "ought" to.
Whether this is easier or not isn't the question; such a practice makes maintenance difficult because people generally expect code to work like Java ought to. They aren't expecting unchecked application exceptions.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #118,674
9/24/03 1:58:01 AM
|
Re: Checked Exceptions: A Failed Experiment
My point was that people abuse the nature of RuntimeExceptions in order to avoid having to declare anything, so you end up with code that doesn't use checked exceptions when it "ought" to.
Hmmm ... kinda assumes that there is a time when one should used checked exceptions. In your opinion when are checked exceptions to be used, and when should they not be used?
BTW, Bruce Eckel suggests using RuntimeExceptions everywhere and wrapping checked exceptions from third party code in a Runtime exception wrapper when they cross the border into your code. My approach is to simply use "throws Exception" on any method that might throw any kind of exception. I rarely care what the specific exception is.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #118,686
9/24/03 8:47:41 AM
|
Note the quotes: "ought" to.
Bending the paradigm simply makes things difficult for other programmers maintaining your code, unless it is bent the same way all the time. While I personally dislike checked exceptions - at least when required all of the time; as I mentioned it's handy sometimes to remind me what might get thrown - I've also worked with people that needed such a crutch all of the time. As a result, in mixed shops of varying ability levels, I think that people ought to use checked exceptions. They're expected, and one of the keys to maintenance-friendly programming is "do what's expected".
I've mentioned this [link|/forums/render/content/show?contentid=100013|before], but it bears repeating: Java is a giant compromise that allows mediocre and good programmers to co-exist without killing each other. When I'm programming for/by myself, I don't use Java, for reasons including things like checked exceptions.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #118,709
9/24/03 1:15:01 PM
|
Thanks
Thanks for the clarification. That's certainly a reasonable position.
In a mixed-skill shop (actually, any multi-programmer shop), I would encourage the group to establish coding standards or best practices that are reasonable and appropriate for the group. A common approach to exception handling (that addresses the checked exception issues) should be one of those practices.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #118,621
9/23/03 7:10:30 PM
|
Bad of course
and the reason was nailed - I've seen way too much code written that simply swallows and ignores exceptions. This has the lovely effect of causing an error to happen much later than I expect and backtracking to the site of the error is virtually impossible. I'd rather that the developer were oblivious to the possibility of the exception and it propagate to a top level handler where I can find it than be swallowed.
More annoyingly - in the streams classes many abstract methods are declared to throw IOExceptions - which can make sense with an unreliable stream like a socket but makes absolutely no sense for a stream sitting atop a string - which will only fail if memory is exhausted. But I still have to have a handler for an IOException because the base class says the method could throw one even though I know bloody well that the actual class never will (and if it does we've got much bigger problems than a simple connection failure).
Checked exceptions are a major failure.
Java is a joke, only it's not funny.
--Alan Lovejoy
|
Post #118,623
9/23/03 7:29:27 PM
|
Hey look - I got a new sig out of that article
James Gosling: Anytime somebody has an empty catch clause they should have a creepy feeling. There are definitely times when it is actually the correct thing to do, but at least you have to think about it. In Java you can't escape the creepy feeling.
In Java, you can't escape the creepy feeling.
--James Gosling
|
Post #118,624
9/23/03 7:30:40 PM
|
Buahahah.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #118,648
9/23/03 10:19:45 PM
|
Designers should ALWAYS look for pushback
As noted in [link|http://www.cato.org/pubs/pas/pa-335es.html|http://www.cato.org/...pas/pa-335es.html], people's actions are already in a dynamic equilibrium with their goals. Therefore any change you make to make it easier for those people to act in accord with your goals is likely to generate pushback as people adjust to try to meet the old set of goals.
The result is that technologies which attempt behaviour modification have a strong tendancy to generate compensating behaviours that undo what the technology intended to happen, and the benefit/loss from the technology shows up in unpredicted ways.
Tools like checked exceptions that make it easier for people to achieve a level of proof that they have accounted for all possibilities are very useful for the minority of developers who were trying to achieve that kind of goal, and who can now do so with much less work. However the attempted enforcement generates pushback from many other developers who just set out to circumvent the inconveniences caused.
Similar comments could be made about security procedures, safety technologies, and many other intersections between technology and actual human beings.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,654
9/23/03 10:35:08 PM
|
OT: I didn't picture you reading Cato stuff. :-)
Another excellent post. Carry on.
Cheers,
Scott.
|
Post #118,655
9/23/03 10:38:52 PM
|
I don't generally
I got there from [link|http://www.cl.cam.ac.uk/users/rja14/econsec.html|http://www.cl.cam.ac...ja14/econsec.html].
Are you saying that I should look for other worthwhile Cato stuff? I'll put the idea on my list. (Currently I am borrowing books from co-workers so that I can get some idea where they are coming from for their job roles.)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,657
9/23/03 10:54:19 PM
|
I can't offer an opinion.
Like you, I've ended up there a few times after doing searches for particular information. I haven't read enough of their stuff to recommend it (or not).
[link|http://www.cato.org/about/about.html|About Cato] lists some things I can agree with, but it's pretty easy to write a moving policy statement that many will be enthusiastic about. It's how those policy statements are put into practice in the real world that matters though, IMO.
The list of people on the [link|http://www.cato.org/people/directors.html|board of directors] includes John Malone of Liberty Media (he may have a lot to do with the dreck on TV these days) and the president of "U.S. Term Limits". They don't give me a warm feeling, but perhaps they're just hands-off directors.
I haven't found a political or philosophical group that I can strongly identify with. I've got a bit of a libertarian outlook, but am not a hard-core Libertarian. I haven't voted for the winner in any presidential election since 1980. :-/
Cheers,
Scott.
|
Post #119,139
9/26/03 8:58:09 PM
|
Cato's been mucking around since the '60s at least
I have been disinterested in tracking their activities (and it was harder through the '70s - Everybody has an Ethics Clause and is Wonderful in all internal docs. Natch)
I recall that several pieces af artful dissembling in support of the Admin strategy of discrediting Viet-war protestors (with no distinction == alllumpedtogether; the simplisticism beloved of Muricans) emanated from this "think-ish tank". The specifics might come back, were I inclined to see how much old stuff is available on the web now.
I don't therefore presume that anyone who writes for them is similarly afflicted -- only that management has not, to my recollection, ever represented other than a Reactionary mindset, and a willingness to speak (however academic) bafflegab as will assist their political aims. Same old same old.
Ashton
|
Post #119,184
9/27/03 3:38:50 PM
|
Re: Cato's been mucking around since the '60s at least
Hi Ashton, Cato was founded in 1977, two years after the end of the Vietnam war.
Also, they're consistently libertarian, not reactionary. They support legalizing drugs, gay marriage, ending farm subsidies, and opposed the war in Iraq (mistakenly, I thought), the PATRIOT act, and so on.
|
Post #119,203
9/27/03 8:27:20 PM
|
Re: Cato's been mucking around since the '60s at least
I recall the mention by-name in "mid-70s" in connection with the Admin war on anti-Viet matters and presumed they were not a new creature. Now I wonder if 'Cato' was a re-use of a previous group's logo -not an- 'institute'..? So much for recollections and time-lines. If calling self 'libertarian' implicitly condones privatization of Soc Sec ... at any rate, this list, commenting on their 25 year anthology This book, published in conjunction with Cato's 25th Anniversary, is a must-have collection of the best articles published by Cato over the past 25 years. It includes such luminaries as Milton Friedman, Peter Bauer, William A. Niskanen, Julian Simon, Carolyn Weaver, George Gilder, Karl Popper, Justice Antonin Scalia, Richard Epstein, Vaclav Klaus, Alan Greenspan, Paul Craig Roberts, Charlotte Twight, Rep. Dick Armey, and P.J. O'Rourke.
These articles span a variety of important issues, including the fall of communism and apartheid, globalization, school choice, Social Security privatization, technology and the new economy, and personal freedom. They show the power of ideas to change the world around us -- especially the idea of liberty. More and more countries around the world are opting for free trade and free markets, and the Cato Institute has played an important part in popularizing those policies to a worldwide audience. This is definitely a collection to treasure by all those who love liberty. ..appears to reflect the spread: when you can find Karl Popper.. Scalia!! Dick Armey! and PJ O'Rourke [ Eat the Rich] courted by the Same Group -?- I must -continue-to- wonder, WTF DO They Mean? Ashton
|
Post #119,183
9/27/03 3:26:35 PM
|
Re: Designers should ALWAYS look for pushback
But checked exceptions don't actually let you get that level of proof! Java's exception language is too impoverished to say the sorts of exception conditions that you want to be able to say. (And the effect languages that do, are generally too complicated to be usable in practice.)
Personally, I don't think that checked exceptions are the problem: I think exceptions are the problem. Or more precisely, the semantics of exception handlers are the problem. Which handler catches an exception is something that can be known only at run-time (since it depends on the precise call chain), and as a result it's really, really hard to reason about who handles what. Exception handlers sneak dynamic scoping back into our programs through the backdoor.
I don't know how to fix that yet, though.
|
Post #119,729
10/1/03 2:11:30 PM
|
How do you do "meta" flow of control?
There is a natural conflict between the desire to create semantics for "exceptional" program flow, and the desire to keep program flow highly structured. Exceptions are a better compromise for this conflict than either returning error codes which the caller has to check and react to, or the solution of using goto for exception handling.
The problem isn't in my eyes that exceptions are reintroducing dynamic scoping - it is that they are providing something too close to a goto for some people's needs.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #119,731
10/1/03 2:38:21 PM
|
Another possible solution to exceptions...
...would fall along the lines of specifying a delegate or function to call in the event that an exception occurs within some scope. In Smalltalk, for example, you typically send a code block in the "Unwind" parameter that will execute in the case of a rollback.
In any case, exceptions come in many shapes and sizes. For the most part they are synchronous events that are usually handled in an asynchronous manner (at least asynchronous when compared to the context in which they are run). On a small scale, they mimic if-then-else or goto logic. On a larger scale, they can introduce havoc into the sequence of the program.
|
Post #119,846
10/2/03 1:53:57 PM
|
Not appropriate for the situation being discussed
The desire was for static verification of what exceptions would be called and how they would be handled. Dynamic runtime solutions don't address that desire.
Besides which, I am somewhat puzzled by how your proposal differs from what I am used to thinking of as the usual way you do exception handlers in a dynamic language. (Perhaps my confusion is due to the fact that I'm thinking about languages like Ruby which had Smalltalk as an inspiration.)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #119,854
10/2/03 2:22:40 PM
|
Actually I'm mostly interested in what...
...Neel is tossing around as the alternatives for his implementation, so I'm just engaging in a little idle speculation. :-)
As far as I can tell exceptions involve two things: (1). a set of code to run when an exception occurs; and (2). a continuation point to jump to once that code is completed. I gathered from your assesment that you think these features have been reduced to a glorified goto construct (reversing the order i just gave). My point, if there was one, was that instead of being a label to which one branches to, the code to be executed can also be thought of as anonymous function which gets fired when an exception event us triggered. No comment was given on the effect in terms of continuation.
Anyhow, other than establishing whether an event is handled or whether it simply throws the exception up the continuation stack, the checked exception handling in Java doesn't give any other clues to the compiler (for static checking purposes). Might be valuable information, but it provides no information beyond the propagation.
|
Post #119,880
10/2/03 6:02:06 PM
|
What my thinking on this is...
In the original Go To Considered Harmful paper, a number of still valid uses for goto were listed. Exception handling was one of those.
AFAIK, exception systems were created to provide for an "exceptional program flow" mechanism which was still structured, attempting to eliminate a problem that goto was still used for.
So it isn't that exceptions come down to a glorified goto, it is that they are good enough at subverting the structured flow of control that they can share some of the problems that goto has.
See [link|http://c2.com/cgi/wiki?AvoidExceptionsWheneverPossible|http://c2.com/cgi/wi...sWheneverPossible] for an entry point into a similar discussion.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #119,921
10/2/03 10:34:48 PM
|
Re: Actually I'm mostly interested in what...
What I'd like is for exception handlers to be lexically scoped rather than dynamically scoped. For example, consider the pseudocode: \nfun make_foo() {\n try {\n lambda(){ raise Error; }\n } catch (Error) {\n print("Error caught in make_foo!");\n }\n}\n\nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n}\nIn a conventional exception system, running main() would result in foo() throwing an error that would be caught in main, and the message that main prints would be "Error caught in main!". This is dynamic scoping -- the exception handler chosen is the nearest enclosing handler live on the call stack. I'd like to try a lexically scoped exception system. In this version, the exception thrown in foo() would be caught by the lexically-enclosing exception handler -- that is, the one in make_foo(). So the printed message would be "Error caught in make_foo!" As it happens, a lexical discipline offers more powerful control flow than a dynamic one (you can write call/cc with it!!), but it is also easier to analyze in a modular way. But this isn't the whole story. To make such a system really useful to the programmer, you still need a type language that can express differing sets of exceptions concisely and precisely, and that's a hard problem: the two needs are at cross-purposes. But the lack of such is what makes Java's checked exceptions mostly useless.
|
Post #119,974
10/3/03 10:52:18 AM
|
Why not include the exception processing in the lambda?
Not sure I understand why the exception processing is not bundled as part of the anonymous function: \nfun make_foo() {\n lambda(){ \n try { \n raise Error; \n } catch (Error) {\n print("Error caught in make_foo!");\n }\n }\n}\nWould the catch not then be lexically scoped within the lambda function? I guess I don't understand what you are trying to. In the current languages, the exception within make_foo would only be trapped if the error were in the creation of the lambda function - not in the invocation. Also, I gather you still think the continuation point should be based on the point of invocation - not the point of defintion. So do you think the next statement executed after the try-catch in the main block? \nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n print("here's where i end up when all is said and done?");\n}\n
|
Post #120,007
10/3/03 3:21:13 PM
|
Re: Why not include the exception processing in the lambda?
The exception isn't part of the lambda, since I was trying to come up with the shortest example that illustrated the issue I was talking about. :)
Also, I gather you still think the continuation point should be based on the point of invocation - not the point of defintion. So do you think the next statement executed after the try-catch in the main block?
\nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n print("here's where i end up when all is said and done?");\n}
I'm not sure what you mean by "continuation point should be based on the point of invocation", but I do want execution to continue normally after the exception is handled (that's kind of the point of an exception, after all!). So your example should print \nError caught in make_foo!\nhere's where i end up when all is said and done?\n
|
