phil swenson wrote: > > On Aug 18, 4:48 pm, Peter Becker <[email protected]> wrote: > >> phil swenson wrote: >> So you are saying it is better to quietly change behaviour than to make >> a change to an API that breaks source compatibility? I certainly would >> not agree to that. >> > > So every API written in every other language ever written in the > history of software got it wrong eh? > How do you infer that? In fact you get the other extremes like the MS APIs where no method every gets changed, they just add "Ex" or numbers at the end for the new versions. Not pretty either, but it is one way to deal with the problem. > Exceptions mean something went wrong. You will detect this when it > happens (testing, iterative dev). And again, it's almost always > because of a bug or something else you can't gracefully handle (like > server down as you mention). If you decide to handle one of these > conditions, that's fine - but usually it's better to let the condition > bubble up to the top thread an notify the user/email the admin. > > > >> Sorry, but I call BS on that. SQLExceptions get thrown when the DB >> server is down or in trouble, when the network has issues and possibly >> other reasons that you do not encounter in test environments, so your >> testing won't help. >> > > Ok, I modify my original claim of "it's almost always a bug" to "it's > almost always a bug or a condition that you can't do anything about in > code". If your db server is down, all you can do it manually > intervene and get the thing running again. If you are in a scenario > where data loss is unacceptable (where you would do a catch/retry), > then you still need to handle runtime exceptions anyway. > Where I might say that runtime exceptions are the evil ;-) > The key is to make the exception known and notify someone. Checked > exceptions usually have the opposite effect. You can say "that's > because people don't use them correctly." Sure, but I still haven't > seen anyone who does use them correctly. It's too much of a PITA. > And my argument is that it is such a PITA (to which I agree) at least partly because the lowest layers (the JDK) did it wrong.
I just realize I might not ever have described what I consider a nice design for checked exceptions. Let me try this. The general assumption is that your code is nicely modularized. Each module should then have a few (normally just one) base exception, saying something like "an operation in this module failed". SQLException could be in theory such a thing. Then you subtype this exception for every error condition. That allows the user to either generally catch errors in your module (by catching the base type) or be more specific to handle certain error cases more gracefully. Ideally your base exception is never instantiated directly, although you might want to allow it in a throws clause. For each method you try to reduce the allowed exceptions. There should normally be some perfectly safe methods (i.e. no exceptions thrown), most other should tend to be quite specific of what can go wrong (i.e. throw a few leaf types of your exception hierarchy). If you find that the same exceptions are thrown all over your API you might want to think about a way to encapsulate the error condition. In cases where IO or similar is involved that probably won't help, but in many cases a bit of restructuring can localize the potential errors. If a layer can not handle an exception coming from below, then it should most likely be wrapped into a suitable exception along the lines of LayerXTechnicalException, ideally enriched by contextual information. The nice thing about such a design is that by reading the method signature it is pretty clear what can go wrong and what can't. With decent names not much documentation should be needed, otherwise the JavaDoc of the exception class as well as the @throws on the methods are great places to put it. If you don't care about the exceptions just catch the toplevel exception of the layer and you are fine. If you do care, catch specific exceptions and deal with them. If you care only about some cases, catch the matching exceptions first and then the toplevel one. Peter --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
