[android-developers] Re: Curious NPE

On Jul 28, 3:18 am, Nikolay Elenkov <nikolay.elen...@gmail.com> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en