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

[Andrew Haley]

Ranjit Mathew writes:
 > On Tue, 8 Mar 2005 11:10:50 +0000, Andrew Haley <aph@redhat.com> wrote:
 > > Ranjit Mathew writes:
 > >  > Tom Tromey wrote:
 > >  > > I'm checking this in on the trunk and the 4.0 branch.
 > >  > >
 > >  > > This adds a '-f' option to gcj-dbtool, to avoid the existence check
 > >  > > for the .so.  This can be simpler to use when building an RPM, where
 > >  > > the .so will not be installed at the time the .db is built.
 > >  >
 > >  > The other day I found out that gcj-dbtool crashes with a
 > >  > NullPointerException if the order of the JAR and DSO files are
 > >  > switched (as was written in the GCC wiki before I corrected it) as
 > >  > it tries to read ZIP entries from the DSO. A full stack trace might
 > >  > also be nice instead of just printing the exception IMHO.
 > > 
 > > 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.

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

Andrew.