One respectable reason

Post #143,714 by admin 2/27/04 4:36:46 PM Reply	One respectable reason Fragile method signatures. [link\|http://www.mindview.net/Etc/Discussions/CheckedExceptions\|Bruce Eckel] and [link\|http://www.octopull.demon.co.uk/java/ExceptionalJava.html\|Alan Griffiths] have more to say on the subject. Or read Rod Johnson's book. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #143,718 by dshellman 2/27/04 5:09:53 PM Reply	Re: One respectable reason My understanding of the "fragility" of method signature in respect to checked exceptions is that, too often, developers merely rethrow contained exceptions, creating a large list of exceptions (in the throws clause) tacked to the method signatures. Again, from what I've seen (the the two articles you pointed out are no exceptions...no pun intended), the issues surrounding the fundamental problem with checked exceptions has more to do with how developers deal with them, and not the concept, itself. For example, the fragility issue should be solved by properly catching exceptions and rethrowing the proper one(s) for the given layer. If development is approached via layers, then each layer should have its own exception hierarchy. This keeps the number of exceptions thrown to a minimum (usually just one). Bruce complains about code readability and how developers misuse them. My problem with that is that I think they were added to the language for a purpose, and that for developers to ignore them (or treat them improperly) is to make for bad development. So, it's not a problem with checked exceptions, themselves, as it is a problem with training developers to think differently about how they code. Just as test-first coding requires a different mindset, the user of checked exceptions requires the developer to approach development with a particular mindset. More specifically, a high percentage of code exists to handle error conditions (in whatever form). If a developer approaches development is the attitude of "just get the job done," then they'll take shortcuts (some of which will be the misuse of checked exceptions). However, if they approach development with the opinion that there be no holes, and that error handling is a significant part of what they do (just as testing, etc. should be), then checked exception won't get in the way. In fact, they'll help (because the compiler will help them be honest). Most of the real complaints I've heard are either based upon developers misusing them, and because many libraries and API's don't use them appropriatly (especially the way the Java libraries are...which is admittedly painful). Of course, I'm not one to say that everything should be a checked exception, either. Unchecked exceptions are important, though I was surprised that Alan Giffiths main thought on them was programmer error. There are two sets of "exceptions" that are non-checked in java: runtime exceptions and errors. One is for programmer errors (runtime exception). Errors are for situations where your app probably can't handle it, such as out of memory errors. Regardless, I think they both should be used appropriately, but I don't think that checked exceptions are inherently "bad," though they are certainly misused too much (just like C pointers, inheritance, etc.). Dan
Post #143,721 by Arkadiy 2/27/04 5:30:34 PM Reply	The problem with Java model is that I cannot declare exception "not thrown" in the implementation of interface. I do not think a solution is possible within the confines of static type checking, and that makes Java's checked exceptions bad. -- The number of the beast - vi vi vi --[link\|http://c2.com/cgi/wiki?QuotesOnComputers\|Delexa Jones]
Post #143,723 by dshellman 2/27/04 5:37:26 PM Reply	Re: The problem with Java model is that I cannot I'm not sure why you think that's "bad." I'm assuming it's because, since your implementation of the interface doesn't actually throw the exception, that it would be nice to not have to declare it. However, the client of that interface should view your implemetation as just that interface, in which case, the designer of the interface made the decision that it should be part of the signature (whether they were correct or not is another thing). In other words, a checked exception in a signature helps define that method, regardless of whether it's used or not (just like parameters can be ignored, but are still there). My point is that it may be the poor design of the interface, or it may be that the designer wanted the user of that interface to be aware (and effectively force them to handle the interface a certain way). I don't see it as a problem with the concept of checked exceptions, though. Dan
Post #143,748 by CRConrad 2/27/04 7:01:59 PM Reply	But that would (i.e, does) defeat the whole purpose! Dan Shell-s out his two cents: My understanding of the "fragility" of method signature in respect to checked exceptions is that, too often, developers merely rethrow contained exceptions, creating a large list of exceptions (in the throws clause) tacked to the method signatures. [...] the fundamental problem with checked exceptions has more to do with how developers deal with them, and not the concept, itself. Nope, sorry, you're wrong, it's the concept: You see, "checked" exceptions are inherently at cross-purposes with the main idea behind why exceptions were invented in the first place. You illustrate this self-contradiction yourself, in the following (only slightly abbreviated) quote: For example, the fragility issue should be solved by properly catching exceptions and rethrowing the proper one(s) for the given layer. If development is approached via layers, then each layer should have its own exception hierarchy. [...] I think [exceptions] were added to the language for a purpose Yup, they certainly were. And that purpose was "Centralised Exception Handling". The idea was, that in stead of returning error codes or something from each and every function / method (and therefore having to handle them, at least to the extent of returning the same or another error code upon receipt of one, in each and every function / method), you would just "throw an exception" -- just a new name for "returning an error code", if you will -- at the point where the error occurred, and then it would automagically trickle back up the call stack to the one most suitable point you wanted to deal with this particular kind of error. The only really significant difference from the old "return an error code" system -- and thus the only reason to change systems in the first place -- was that this would happen without you having to explicitly screw around with the code of the intervening "layers" (to borrow your terminology) every time you change something to throw a new kind of error several layers removed from where you're handling that kind of error. Now, introducing the "checked exception" in Java, Sun managed to... Undo the whole idea, AFAICS. It's like, first somebody goes all "Hey, let's invent something we'll call an 'exception', so errors can occur in one place and be caught in another, without having to constantly make sure to transfer received error codes back up the call stack through several layers!" And then Gosling goes, "Yeah, great idea! Only, to make it even better, we'll make sure every time someone changes their error handling, they will have to change the code of each intervening layer!" Like, HEL-LOO... Anyone at home behind that beard??? , and that for developers to ignore them (or treat them improperly) is to make for bad development. So, it's not a problem with checked exceptions, themselves, as it is a problem with training developers to think differently about how they code. No, (for once) you're wrong to blame the developers (for this particular problem). It is unreasonable to expect them -- us -- to think sensibly about how to handle "checked exceptions", because there IS no sensible way to think about such a self-contradictory concept. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) You know you're doing good work when you get flamed by an idiot. -- [link\|http://www.theregister.co.uk/content/35/34218.html\|Andrew Wittbrodt]
Post #143,878 by drewk 2/29/04 12:25:47 AM Reply	ICLRPD (new thread) Created as new thread #143877 titled [link\|/forums/render/content/show?contentid=143877\|ICLRPD] === Implicitly condoning stupidity since 2001.
Post #143,963 by dshellman 3/1/04 7:37:54 AM Reply	Re: But that would (i.e, does) defeat the whole purpose! Though I agree that "exceptions" were meant to move away from return codes by "centralizing" the error handling, I disagree with your definition of "centralize." Checked exceptions merely provide compile-time checks on error handling. They are neither good nor bad, but act as a tool by developers. They force developers to think about exceptions by forcing them to make the compiler happy. Centralization requires a definition of what central is (that is, define the point). If centralization means a particular "layer" within code, so be it. If it means the main thread of execution, fine. For GUI applications, it may mean pushing the original exception up the stack far enough to display to the user. In a batch system, where there is no user, that central location may be completely different. It's a question of where (locality). I think a better argument against checked exceptions is how they provide a capability that is not easily handled by unchecked exceptions. Again, it comes down to providing a compile-time check. I understand that many here prefer run-time checks rather than compile-time ones. I think that more a taste, and I have no issue with that. My only real argument is that checked exceptions work well in certain circumstances and that I've found them useful. However, I heartily agree that they have been misused, especially in the core JDK libraries. This has given them a bad name. It's a question of well designed use. Dan
Post #143,968 by CRConrad 3/1/04 9:10:07 AM Reply	Sorry, either I don't get your meaning, or you didn't mine. Dan S continues the discussion: Though I agree that "exceptions" were meant to move away from return codes by "centralizing" the error handling, I disagree with your definition of "centralize." How can you do that, when I didn't give one? Checked exceptions merely provide compile-time checks on error handling. There's checks and there's checks... Checked exceptions don't "merely" provide "compile-time checks on error handling", they provide paranoid, self-contradictory, concept-defeating compile-time checks on EVERY STEP BETWEEN error and handling. They are neither good nor bad, but act as a tool by developers. No, they are bad, because they act as _a hindrance_ to developers. I mean, heck, this is a _fact_, attested to by heaps and reams of evidence all over the Net. (Sure, you may want to call that evidence "anecdotal"... But isn't all evidence "anecdotal", in a way? Doesn't it become a little less "anecdotal" [as in "of no consequence"], when it includes your own observations? It sure looks like more of a fact than do the misguided intentions of Java's designers, at least.) They force developers to think about exceptions by forcing them to make the compiler happy. No, they obviously don't -- what they really do is: They force developers to catch a lot of exceptions to make the compiler happy, which leads to UN-thinkingly catching (often, just to "swallow" and forget) TOO many of them. You might want to blame that on the developers, but: A) It's a perfectly natural "path of least resistance" reaction to an overly restrictive system, B) this reaction seems blindingy obvious (at least to me, but I have to admit I wasn't there when Java was designed), and as such should have been easily predictable, C) so in total, they DON'T lead to what you claim they were intended to lead to, but rather the opposite. Ergo, they don't work. (Yeah, it's really that simple: They just don't work, in the real world outside Gosling's beard.) Centralization requires a definition of what central is (that is, define the point). If centralization means a particular "layer" within code, so be it. If it means the main thread of execution, fine. For GUI applications, it may mean pushing the original exception up the stack far enough to display to the user. In a batch system, where there is no user, that central location may be completely different. It's a question of where (locality). No, it is NOT "a question of where (locality)", and no, 'centralization' in and of itself does certainly NOT require a definition of "what central is". Centralization is a concept, an idea -- exactly what point ("locality") you center on, is implementation-dependent and doesn't matter for the concept per se. That is, exceptions were supposed to let you have your error handling at some arbitrary central point of your choice. The point (of my argument, not the central one we talked about above) is, exceptions were supposed to let you handle your errors at this arbitrary central point of your choice, WITHOUT having to touch all OTHER areas of code in between where the error occurred and where it's handled. Once you defeat that, you've defeated the whole idea of exceptions, and can just as well go back to return codes -- because you've just re-created them, only bloated by several orders of magnitude. How can you not see this?!? Or, if you still want to claim there's a difference: Could you explain exactly what it is, "as if to a four-year-old"? I think a better argument against checked exceptions is how they provide a capability that is not easily handled by unchecked exceptions. Huh? If they actually provided any capability that other systems don't, wouldn't that be an argument FOR them? Again, it comes down to providing a compile-time check. I understand that many here prefer run-time checks rather than compile-time ones. I think that more a taste, and I have no issue with that. Heh -- yeah, I'm well known here for my anarcho-libertarian preference for run-time checks and aversion to compile-time ones... Sorry, but more seriously, that kind of compile-time checks isn't the only one there is. My only real argument is that checked exceptions work well in certain circumstances and that I've found them useful. Hmm, yeah, well... Hard to argue with experience. (If you're sure you haven't somehow deceived yourself into thinking so? :-) However, I heartily agree that they have been misused, especially in the core JDK libraries. This has given them a bad name. It's a question of well designed use. I think "well designed use" of a mis-feature is a contradiction in terms. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) You know you're doing good work when you get flamed by an idiot. -- [link\|http://www.theregister.co.uk/content/35/34218.html\|Andrew Wittbrodt]
Post #143,883 by bluke 2/29/04 1:33:07 AM Reply	What ends up happening ... is that you have reams of code catching exceptions, wrapping them in some new exception and throwing them. What value have you added by wrapping the original exception 10 times? Take a typical example. Your low level data layer fails getting data from the database for some reason (e.g. because the database is down). In most cases there is nothing that you can really do with this exception except log the error and present an error message to the user. What value is there in making all the intermediate layers catch the exception wrap it in a different exception and throw the new exception? What value have you added? The bottom line is that the topmost gui layer should catch the exception and present the error message whether or not you wrapped the exception 10 times or not.
Post #143,964 by dshellman 3/1/04 7:38:49 AM Reply	Re: What ends up happening ... I think 10 times is a little excessive. And I think the database access (specifically SQLException) is also a poor example, as it's debatable whether it should have been a checked exception in the first place. Dan
Post #143,989 by tuberculosis 3/1/04 12:18:27 PM Reply	Re: What ends up happening ... [i]I think the database access (specifically SQLException) is also a poor example, as it's debatable whether it should have been a checked exception in the first place.[/i] OK but its debateable whether any exception should be a checked exception. For instance, InputStream - a fully abstract class - insists than any method may throw an IOException which must be caught (its checked). Yet there are instances of InputStream that do not throw this exception - yet the programmer is still burdened with writing code to handle exceptions that will not be thrown. This is a fundamental problem with static typing and hard wired method signatures. InputStream in = new StringBufferInputStream(buffer); int c = -1; try { c = in.read(); } catch(IOException ex) {} // won't really throw Of course, you can't exactly know that in is going to reference something that won't throw. My biggest complaint though is that checked exceptions leak concerns of implementation into the interface. This results in very brittle systems. The tree of research must from time to time be refreshed with the blood of bean counters. -- Alan Kay
Post #144,018 by bluke 3/1/04 3:02:14 PM Reply	You didn't answer the question ... What value is there in wrapping exceptions? 10 was obviously an exaggeration. What do you think should have been an unchecked exception?
Post #144,088 by dshellman 3/2/04 9:13:43 AM Reply	Re: You didn't answer the question ... Wrapping exception is used to create a facade to the next layer. So, since SQL exceptions are checked, I can do one of two things: I can wrap them and rethrow them as application-specific checked exceptions, or I can rethrow them as unchecked exceptions. For SQL exceptions, I've seen both. Personally, I usually wrap them in checked exceptions because I like to associate a prettier error message with them as close to where it happens (I have more contextual information at that point). Then, I have a simple application-specific checked exception that the higher layer (say the presentation layer) can deal with in a generic, simple fashion (in some cases, the higher layer may not even need to know anything about the exception because it contains enough information for display purposes, but that's dependent upon the application type and how it's designed). I approach unchecked exceptions in this way: if it's a programmer's error (i.e. a null pointer exception or something like that), an error (i.e. out of memory), or something that can't be handled and dealt with at a lower level (because the contextual info isn't helpful, or it doesn't make sense to), then using unchecked exceptions works well. However, if it's a application exception, such as bad input from the user, database going down (and this one can go either way...it depends upon the interface to the user), etc. then checked exceptions are nice because they can usually be handled nicely by the upper layer. Hope that answers your question. Dan
Post #144,187 by bluke 3/3/04 5:05:16 AM Reply	A number of comments 1. in any given layer the exception can occur far down the call stack. Especially if you write short methods you may be far down the call stack when you catch and wrap an exception. This means that every method above you in the call stack needs to do something with the exception, probably just throw it, clearly a waste. 2. If each layer only throws 1 exception you lose information. The UI may want to display different pages depending on the exception. For example, if you receive a licensing exception the UI may want to display a licensing page, while a validation exception may redisplay the form. By wrapping the exceptions in a general exception youy make it hard for the client to figure out what really went wrong. The client then has to go and look at the wrapped exception and get the cause. 3. Many times you have a number of layers and they just wrap the exception without adding any new information.

Welcome to IWETHEY!