On Jul 28, 3:18 am, Nikolay Elenkov <[email protected]> wrote: > 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.
I guess I just don't have a problem with that. I don't see that it impacts my productivity. I occasionally have problems with what some interfaces have declared as checked vs. unchecked, but then I'm free to ignore or not ignore at my discretion. Honestly, IOException is too important to ignore, in my experience, except when shutting things down. I've been more often burned by ignoring stuff like that rather than dealing with it at the point where it becomes a problem. And even MORE often than that, I've been burned by others' code ignoring checked exceptions that were setting up bad states in a system. In your example, it doesn't necessarily matter to me what "DataAccessException" means. I just log it or notify the user at the end of its concern and go on. The fact that I have a log at my disposal is good enough for my purposes. I'm smart enough to follow a stack trace, so I don't see it as a problem to deal with. Maybe it's just a matter of disposition or domain or employment. I've often dealt with highly state-driven software that needs to understand exactly where something went wrong so it can retry, rollback, or notify on very specific actions. Checked exceptions will keep you honest in those cases. > 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. Maybe that's just a bad interface. Sorry to hear you've had to deal with that. > 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. No, definitely. :-) > 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. Well this is where we differ. I haven't had those problems you're describing. Having my java tooling automatically generate a try/catch for me is less trouble to me than diligently checking return codes from a functional API. There are some Java APIs that have poorly design exception mechanisms. Reflection is one, in addition to the silly NumberFormatException. That's a problem with those interfaces, but not really a problem with checked exceptions at large, the way I see it. And anyone who uses finalize() should be shot unless they are licensed to carry a gun. This is pretty much the sum of my response to the links you sent. You say there are benefits -- but what are they? None of the references you gave spell this out. They give a few short examples of stuff that could be better, but no examples of large scale system or any kind of systematic approach to error handling. I don't buy the productivity argument, because I don't see it as a problem, especially when your intent is to make a bulletproof app with robust messaging. > > 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. Again, I think this is where we differ. I don't find that I spend lots of time having my java tooling generate simple boilerplate if I need it. > 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. Still disagree, because for me, the lifetime benefits of forcing myself to be honest with potential errors has outweighed the small cost of having to deal with the times they can be ignored or wrapped. Again, the biggest problem I've had is with other peoples' code intentionally ignoring exception that should have been handled. I've just gone through this exercise on a codebase that I'm refactoring right now. The original author chose to absorb a lot of potential trouble into a simple return of null from a "master" function. This has caused me a great deal of pain and it would have been a whole lot better if the API had just declared some checked exception -- ANY exception -- to force the caller to deal with it. My reworked solution uses checked exceptions to set up very predictable and recoverable situations while reducing the number of lines of code and increasing readability. Just to be clear, I'm not just a "java guy". I'm totally a current technology chaser with fairly broad experience whot has happened to make great use of checked exceptions to create bulletproof Android and web applications. I'm open to seeing any alternatives toward that end. And again, I just can't subscribe to the productivity issue without seeing some strong large-scale examples. 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
