Patch: FYI: add '-f' option to gcj-dbtool

[Ranjit Mathew]

>  > > Hmph.  gcj-dbtool doesn't crash -- it reports, correctly, that the zip
>  > > decoder returned an exception.
>  >
>  > Perhaps, but it was a simple mistake on the
>  > user's part and this:
>  >
>  >   ~/src/tmp > gcj-dbtool -a foo.db foo.so foo.jar
>  >   error: could not update foo.db: java.lang.NullPointerException
>  >
>  > does not seem to tell him (IMHO) what his mistake is or
>  > how he could correct it.
> 
> Sure, but the right place to fix it is in the zip/jar decoder.
> Presumably it's better to return a JarException with an appropriate
> error string than a NullPointerException.

Right (as I discovered while trying to "fix" this - simply
checking "if (entries != null)" was not enough).


> I object to the use of the word "crash" used to describe an
> inappropriate error message to incorrect input.

In this particular case, as an *end user* I
would disagree - a Java application exiting
unceremoniously with a NullPointerException
does look like it has crashed (similar to a
Windows GPF, a GCC ICE, etc.).

As a *developer*, I understand what is
causing the error and how to rectify it.

It's a matter of perception and this
debate is rather moot...

I could have used a vaguer term
like "barfed"... :-P

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/