On 26 June 2010 07:46, Wildam Martin <[email protected]> wrote: > On Fri, Jun 25, 2010 at 20:25, Reinier Zwitserloot <[email protected]> > wrote: > > I just don't get IDEs. Eclipse does something similar > > (e.printStackTrace() I believe). This, AND what netbeans does, is > > completely ridiculous. Almost always the wrong thing. The only obvious > > thing to do when automatically generating an exception handler, is > > this: > > > > catch (CheckedEx e) { > > throw new RuntimeException("missing handler", e); > > } > > Uhhhh - I would never ever do this. > 1. Just because Microsoft did not implement checked exceptions it does > not mean, .NET does it better. I for myself appreciate the checked > exceptions. They make a lot of sense. People complaining about > boilerplate code generated are using it wrong IMHO. It is similar to > copying a file. There is no ready made method in the Java libraries to > copy a file and when learning Java I REALLY wondered why there isn't. > The conclusion I had after a while: There are so many ways and > possible requirements when copying a file that everybody needs to > write a copy function as required. For opening a file I have written > several wrappers for the most frequent use cases I have. Then I use > the wrapper and don't have to handle the checked exceptions again and > again wherever I open files. And of course there are libraries and > methods that make too much use of checked exceptions (I think it is > some method in the net package that throws 3 or 4 checked exceptions > that needs to be handled (don't remember exactly) - however I wrote a > wrapper for my 90% use case and done. Anyway I had several discussions > with .net and Java developers and I prefer the way it is designed in > Java. >
So checked exceptions are good because: - they're different to what Microsoft does - they force you into writing your own library code that swallows them > 2. A runtime exception means, that the developer is not pushed to > implement a handler which means the developer can easily forget to > handle an error that possibly is produced by a called method. > That's the whole point! When developers *are* pushed to handle the exceptions, then one of 3 things will often happens: - they're just swallowed, maybe logging a stack trace - they're inappropriately handled at too low a level - the calling method gets declared as 'throws xxx'. Once 4 or more such exceptions are thrown, just replace this with a single 'throws Exception'. Watch as this signature pollutes every method in your codebase. re-wrapping an exception as an unchecked exception is often the best choice, just take a look at how Spring handles SQL exceptions. Checked exceptions work fine in the sort of example code that books give, or in training courses. But once you hit a decent size codebase, with the exception and handler being separated by 4 or more method calls, then checked exceptions become a nightmare of boilerplate and bad practice. > Out-of-memory errors are a good example of where runtime exceptions > make sense, where it does not make sense to try anything further. On > the other hand, an I/O error is not in general a reason to vomit and > do an epic fail. It rather makes sense to try again because it might > be a short interrupt of network connection. I have seen several > Windows applications completely crashing because network connection > was missing for 5 or 10 seconds. > > Nobody ever said not to throw exceptions, or not to catch and handle them. Just don't nag the developer into catching them at an inconvenient time. > > > That logger action just lets the process continue, while the state is > > most likely corrupted. Horrible solution. > > Indeed! - The last thing I ever want, is my application crashing - > this is the worst user experience on the client (all edits lost) and > completely stopping the service for a server application (assuming it > is the main thread where the error occurs). An application should > always come to a graceful end. > Given the risk of out-of-disk or out-of-memory exceptions, I ALWAYS write load/save routines in a try/catch block that picks up on all Throwables. Checked exceptions don't goad me into this, they just add a ton of boilerplate to something I'm doing already. > -- > Martin Wildam > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
