On Aug 23, 12:36 am, Martin Wildam <[email protected]> wrote: > > The question is: How really to use them right? I think this is a > desired result of this discussion. :-] >
A full and exhaustive treatise doesn't exist, but there are a few rules almost everyone can agree with, and yet these rules are not followed by the JDK, probably because we didn't know any better back then. i.e.: - Don't throw a bazillion checked exceptions. (Reflection API, I'm looking at you). - Don't create situations where methods are declared to throw exceptions that you know, _FOR SURE_, and which a sufficiently advanced compiler could even sort out for you, couldn't possibly happen. Stupidest example of this: the AccessException that most reflection methods throw. If you've called .setAccessible() before, it is DEFINED as COULD NOT POSSIBLY happen. This is ridiculous usage of a checked exception. The same happens with new String(byteArray, "UTF-8") - the JLS definition again states that an UnsupportedEncodingException could not possibly happen, and the same happens yet again with filter input/outputstreams working on ByteArrayInput/OutputStream - The declared IOExceptions just cannot happen, ever. (Unless the filter operation can itself generate IOExceptions, which makes the problem even worse: You can no longer tell from the API of a FilterIn/OutputStream if it can be a source of checked exceptions, or if it is only passing through the exceptions of the stream it's wrapping. - Make sure your interfaces throw a plenty broad exception type. failing at this game: Servlet API, java.lang.Runnable. - If you're going to use checked exceptions, make sure they are borderline useful, and not just a general flag as: Oh, operation failed, and I'm not going to tell you how. Exceptions of that sort should be unchecked because in 75% of all cases you just want the thing to move right back up the stack until a centralized 'something went wrong' handler, which will be catching everything. Failing at this: SQLException, though recent JDBC versions are working on improving the situation. > The ten commandments are also very old posts Mixing religion into talk about programming is a very bad idea. But, I'll take your point that just because something is old does not mean it's wrong. However, who was attacking Joel's post as old? I've been relentlessly bashing Joel's opinion on exceptions because it's WRONG, not because it's old. It was wrong when he wrote it. It's still wrong now. > > Never heard of the "Maybe" type - but I am pretty sure that a "Maybe" > would be the last thing I would like having to deal with. So, why are you liking Joel's post so much? The only alternative he offers is something that boils down to maybees. Well, or ints as error code, but I take it we all think that a horrible idea, right? (And, technically, error codes as ints is a maybe as well. Just a really, really, _really_ bad, non-namespaced, unreadable version of it) A Maybe is simply an alternate form of null: You can ask a Maybe if it has a value, and you can ask a Maybe for the value. If it didn't have a value, then that would throw an exception. (Uh, I see a chicken and egg problem here...) - though the more likely type of object to use here would be an Either. An Either holds either an object of type A, or of type B, and it has a method where you can ask which is which. Again, what would happen if you then asked for the wrong one? The 4 methods are usually 'isLeft()', 'isRight()', 'left()' and 'right ()'. Both Maybe and Either can preserve typing via generics. I'm not saying its a good idea. I'm saying its the only way to make Joel's "no exceptions" story work. > > In the past (even before using Java) I have used a common accessible > error object (containing status information and error/warning message > lists) - a static one accessible from and for all levels within my > application. Oh, yeah, that'll go over real well with threading. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
