phil swenson wrote: [...] > Another issue I didn't mention is checked exceptions pollute the > interface. Lets say you have a public API (interface) and add a new > exception type. This makes every consumer of your API's code break. > This violates the concept of having an API "contract". So with > checked exceptions either you are forced to 1) violate the contract or > 2) not throw the exception you want to throw and wrap it in an > unsuitable exception or 3) use a runtime exception. 3 is best:) > 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. > people are so concerned with not knowing what exceptions are thrown, > but if you test your projects you will discover when there are > exceptions that are thrown and you want to handle. It's a rare > occurrence. usually there is nothing you can do about it, so knowing > that it will be thrown doesn't really help you out. I mean seriously, > what do you do when you get a SQL Exception? it's almost always a > bug. and a bug that might not be discovered if you used a checked > exception and swallowed it. > 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. Of course you can let it go through and just let your application provide with a generic error message, but there might be better ways of dealing with such an issue, in particular if the DB in question is not your only data source. For example: if your ads are served from a database and that is down, you probably want to fall back to some standard display, not a 500. Of course you could do that by catching Exception/Throwable around the component responsible, but the person integrating the system has to be aware that something can go wrong there.
I guess you could just operate on the assumption that everything can fail and provide a generic error handler for each component, but I don't like this approach at all. In particular I believe that there should be parts of your code that do not throw exceptions at all. With checked exceptions you can distinguish the ones that do from the ones that don't. That approach just doesn't work well in Java because JDK libraries already throw a lot of Exceptions where they shouldn't (in particular the dreaded NPE). But that doesn't seem to allow concluding that the idea of checked exceptions is broken as such. Peter > On Aug 18, 4:13 am, Peter Becker <peter.becker...@gmail.com> wrote: > >> I still believe that the main reason people hate checked exceptions is >> that they have been used badly. >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
