On Jul 27, 1:25 am, Nikolay Elenkov <[email protected]> wrote: > On Wed, Jul 27, 2011 at 5:07 PM, Doug <[email protected]> wrote: > > > 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? > > I never said this, and how is this related to checked exceptions?
I see checked exceptions as a compile-time reminder that it's always a good idea to handle potential errors. This is almost exactly the same concept as diligently checking the return codes from C functions that can fail. I suppose if you are the kind of engineer that doesn't make a priority of checking return codes, then you probably also don't like Java forcing you to do something with potential error conditions. If you are that kind of engineer (and I would argue that you are not actually an "engineer"), then don't use Java. > The whole point is, that with checked exceptions you are forced to > handle or re-throw/declare them even if you don't what to do that > *in that particular part* of your code. Nobody is saying 'we will > ignore all exceptions and keep our fingers crossed'. Truthfully, how often do you really NEED to ignore checked exceptions? It does come up, but not enough for me to get upset that I have to do it. For me, it's a few extra lines of code in a few places. If you don't like writing those few extra lines of code, then don't use Java. > > Who? The posters in your example don't seem particularly smart. They > > appear to me to be lazy or outright complainers. > > Do your own research. 'They' have written multiple books about > Java and other languages. You might not agree with their ideas, > but 'lazy'? BTW, if it weren't for 'complainers' who find faults with > current technology and invent new things, you would still be writing > in assembler or using a stone club. Complainers stop being complainers and become innovators when they come up with something better and make it successful. If you have found something successful that works better than Java, then don't use Java. > > 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. > > Good for you, but that's irrelevant. You might have a stable application, > but one can produce one without using checked exceptions. The fact > that most languages don't even have a concept of a 'checked' exception > is ample proof of this. I'm not saying that it's not possible to make a bulletproof application without checked exceptions. I'm saying that it's EASIER to do it, because the compiler reminds me when things can go wrong. With those reminders, it becomes easier to set up patterns of discipline for error handling. If I wanted to bang out a quick demo or prototype app while making assumptions about my runtime environment and not be concerned about crashes, being forced to deal with checked exceptions can slow down my development. Also, if I'm writing a linear, single-threaded code path, checked exceptions can be a hassle. But that is all I can concede about the difficulties with checked exceptions. For developing large, solid applications with complex interactions that handle the harsh realities of the world (such as bad or missing network connections, limited storage space that can fill up or disappear altogether, unpredictable user interactions, etc) then having checked exceptions remind you of those circumstances is a huge win. 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
