On Jul 26, 11:34 pm, Nikolay Elenkov <[email protected]> wrote: > > I'm sorry I missed that universal memo. Please tell me more? > > Don't take my word for it, start here: > > http://www.mindview.net/Etc/Discussions/CheckedExceptions
>From this article: "My theory is that when someone is trying to do something and you are constantly prodding them with annoyances, they will use the quickest device available to make those annoyances go away so they can get their thing done, perhaps assuming they'll go back and take out the device later." This is just bad engineering (and a bad theory to boot). If an engineer is not disciplined enough to handle known possible exceptions when they can occur, then that engineer needs to consider a new career. The person said the above statement is not a "smart" person talking, IMO. This is a lazy person who can't the handle the structured exception handling and perhaps likes to assume nothing can go wrong. I like it when an API throws checked exceptions because it reminds me that I need to handle potential error cases. I am not lazy enough to write "bad" exception handling, and if I need to ignore an exception, I use the variable name "ignore" to know that I am intentionally ignoring it (which is in the very small minority of the time). In other words, would you expected your city's civil engineer to prove that their building design can handle the load expected of it for regular use? What if that engineer opted out of that proof of their design? Perhaps you don't mind if your favorite restaurant fails their health and safety checks "because they couldn't be bothered" to keep the kitchen clean? > http://www.c2.com/cgi/wiki?JavaExceptionsAreParticularlyEvil This article mostly just harps on very specific cases of exception handling and not on the greater issue of checked vs unchecked. Granted not every exception handling case is very simple, but the caller does deserve to know WHY something failed and not just IF something failed. It's no different than switching on return codes from C runtime functions. The whole argument about "exception only make sense on small code samples" only gives credibility to writing small, well-designed, unit- testable classes. You'll have problem with exceptions if you try to jam too much code in a giant do-it-all class. Don't do that. By the way, when you you advocate NOT checking the return value of C runtime functions? You'd just write to an unknown file descriptor even after a failed call to open() and just wait for the fallout? > Other smart people have been saying the same thing. Who? The posters in your example don't seem particularly smart. They appear to me to be lazy or outright complainers. They don't seem to be prepared to write their code in an environment that needs to recover gracefully from inevitable errors. Or maybe they just like to violate the contract of any interface and hope that all goes well. Or maybe they have no problem constructing buildings that collapse for lack of planning. I've gotten a lot of mileage from exceptions under Android and it's forced me to be diligent in writing bulletproof code. But then again, I actually care about my customers and the user experience of the applications I've written. My apps haven't generated any exception crash in over a year and customer satisfaction is high. Thank you, checked exceptions. Doug -- You received this message because you are subscribed to the Google Groups "Android Developers" 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/android-developers?hl=en
