But that would (i.e, *does*) defeat the whole purpose!

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]

Welcome to IWETHEY!