On Thu, Jul 28, 2011 at 5:29 PM, Doug <[email protected]> wrote: > On Jul 27, 6:35 pm, Nikolay Elenkov <[email protected]> wrote: >> On Thu, Jul 28, 2011 at 3:35 AM, Doug <[email protected]> wrote: >> > On Jul 27, 1:25 am, Nikolay Elenkov <[email protected]> wrote: >> >> On Wed, Jul 27, 2011 at 5:07 PM, Doug <[email protected]> wrote: >> >> > 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. >> >> You are making too many assumptions, but have fun with it. >> I actually write all of my C code in a giant main() function and >> I never ever check return codes. I am that good. I pass around >> NULL pointers like crazy, but it's OK, because I'm a lucky guy. >> Satisfied? > > No, I'm not, because you're not using logic to address to issue at > hand. >
Well, neither are you. You are assuming something I never said, and are building your 'case' from there. As you see, this doesn't work. >> Again, I never said ignore. I said 'don't handle in that particular place'. >> A few extra lines of code multiplied by a hundred places makes for >> a lot code bloat. Don't you just love it when you have to handle >> IOException when calling close()? > > Please answer my question above. How often? In my experience (16 > years) it's not common enough to complain about. Pretty darn often. Every time you need to deal with file IO, connect to a database, or call a network service. Consider a simple data access interface. You might have a file implementation and a database implementation with the same interface. You can't exactly declare it to throw IOException *and* SQLException, but still want to make people handle the exceptions your implementation throws. So you invent a checked DataAccessException and declare it in your interface. You feel pretty satisfied about your abstraction. Then you implement it, wrapping your IOExceptions and SQLExceptions in the shiny new DataAccessException. People use your classes and need to handle errors at some point. But what does DataAccessException mean? Not much. So, they dig in, get the cause and go from there. Neither compiler checking, nor your design by contract have made people's life easier. Or say you need to implement a third party interface. Your implementation needs to use a file, but the interface doesn't declare an exception. You need to stick to the original interface's contract! So what do you do: log and swallow the exception? wrap in up in a RuntimeException? declare all interface methods to throw Exception? None of those are too good. And just the time spent considering it is wasted. You say there is value in checked exception: they force lazy programmer's to deal with errors; they make your contracts explicit; the compiler can check them for you. OK, maybe. But the problems they produce: breaking encapsulation, forcing people to write boilerplate code when they don't need to, making it hard to evolve your design, proliferating endless hierarchies/chains of Exceptions far outweigh the benefits. > There are cases, > yes, but only on shutdown/termination. I don't obsess on those > cases. I do them one and be done with it. It takes at most 1 minute > out of my day. If you can't spare that 1 minute, then don't use Java. See above. It's about writing less boilerplate code and being more productive. Multiply your one minute by the number of times you've had to deal with checked exceptions when you didn't really need or intend to, just because the language forces you to (in your long Java career), add in the time spent considering whether an Exception should be checked or unchecked; even the time spent in this thread, and you will see that you have wasted a lot of time. > >> We can go on forever, but there's not much point. Have fun with >> your exceptions. > > Please make a case for your alternative. I'm listening. Please make > it relevant to Android development, considering the forum in which > we're participating. If you have an axe to grind against Java as a > language, I suggest you do it elsewhere. > I don't have an axe to grind. Java is a good language. Lots of good ideas in it. As for Android, it's a good fit for mobile development: it's widespread, it's fairly high level, but it still lets you get close to the metal when you need to (via JNI, which is a pain, but still); it has garbage collection. It is perfect: no. Is there any chance that the flaws will be fixed: no. Or it will take 5 to 10 years of going through JSR/JCP, corporate struggles and some lawsuits. Fortunately, people are building some really good things upon the JVM, so there are alternatives. To make the relevance to Android development blatantly explicit: those alternatives will let you be more productive when writing Android applications. And hopefully none of those shall have checked exceptions :) -- 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
