On Sat, Jun 26, 2010 at 09:42, Kevin Wright <[email protected]> wrote: > 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
I don't know why Microsoft (by peering to Java) dropped the checked exceptions. Even if they would have decided to not use this in the core libraries, they could have given the developers the option. But - as usual - they nail the rules. And "Swallow" is not the right word here. By wrapping this in my own function I have to decide what to do - I cannot simply ignore it. I could have a wrapper that throws one single runtime exception or returns a boolean false instead or throws an application specific general exception - three options that don't just "swallow" it. I could have another use case where I use the core method again and then I am again reminded that there are possible exceptions and I have to decide again instead of just forgetting about it. > 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 At least logging it is already good thing. Besides development I also have to support my software. So finding a hint in the log is already better as what I get from most other 3rd party software. > - they're inappropriately handled at too low a level I know that there have been plenty of discussions about handling exceptions at a lower or higher level. My opinion: If the level is too high where you try to catch it, you cannot really tell anymore, what really happened - you can just tell, that the whole operation failed (if you are not going to do particular analysis of the stack trace). If the level is too low you might not know if that exception is really important - it might be that just loading of an icon resource failed, which should not be considered as a critical error maybe. > - 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. I am not sure if it is not also written in one of the famous Java books - however, I have a library written that does handle all exceptions and throws an application specific exception where it is wise to do so. In other cases I just raise a warning and continue. Using this library is then very comfortable. You have the checked exceptions to handle but they are thrown where needed - of course it is not always easy to find the balance, but I think handling and rethrowing your own checked - or maybe even unchecked - makes sense. Somewhere I have read the rule of thumb that you should use checked exceptions for errors where it could make a sense to retry or do something else from program logic and unchecked exceptions for errors where it does not make sense to continue the program/module anyway. E.g. if a needed primary configuration file is not found you might not want to handle that error. The scenario you described above - I have never seen this yet - but I do not use 3rd party components extensively - so I might have been just lucky. > re-wrapping an exception as an unchecked exception is often the best choice, > just take a look at how Spring handles SQL exceptions. Might be a good choice in some cases - but I would not do that as a "usual" choice. Spring is a piece of it's own. There are people who love it and those who hate it. I have only got very few to do with it and try to avoid it like hell. That said, I am not working on EE projects so my projects might simply be too small for getting the benefits out of it. > 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. I think, the handling on the lowest level is still better as handling it on the top level. There you also have the most information to put into the logfile. So at least the logging of the exception should be done on the lowest level. > 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. You mean, you automatically save when you encounter an exception - or before you do anything that may cause an exception? - Not sure if I got you right here. To ensure data saving before doing some other maybe failing operation is a good idea - thank you. On Sat, Jun 26, 2010 at 11:23, Fabrizio Giudici <[email protected]> wrote: > Ok, so this is evolving again toward the usual endless discussion > about checked vs unchecked :-) You maybe right. Thanks for pointing that out. Maybe we have all to accept that it depends on the application/use cases, what is the best option. This is also maybe again something that a Java developer might think a few hours when designing a library while on the other side a .Net or Ruby developer already halfway finished. ;-) > I'd only say that I'm in the club of > checked exception supporters and that citing what bad programmers do > with checked exceptions doesn't sound a strong argument to me, as one > might say that with unchecked exceptions bad programmers will never > write a try / catch and produce terrible code... Indeed! -- 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
