db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: [jira] Commented: (DERBY-128) Network Server Gives NPE if SQLException has null arguments (e.g. for ERROR XBM0H)
Date Sun, 05 Jun 2005 11:38:37 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:


> As I see it there are two core issues
>  1) Network Server shouldn't throw an NPE if an SQLException as null
> arguments.
>      You fixed this and I think  your test change is probably good for
> testing that.
> 2)  An SQLException shouldn't  have null arguments.  It should have the
> same number of meaningful arguments as there are {} markers in the
> messages_en.properties  file.
>      For DERBY-19, it looks like Dan changed a null argument to a
> meaningful argument. 
>      For the exception listed in DERBY-128 (XBM0H:) it looks like the
> exception requires only one argument but we were
>       calling the wrong method and passing an extra null argument along
> the way.
> The problem is that once  you fix all the instances of issue 2,  issue 1
> is no longer an issue #:). So,  I think there is no long term test
> solution here.

OK :)

> So I would say
>  File a bug for the XBM0H exception  being generated with null
> arguments.   File a patch plus your NSinSameJVM test.
> The  NSinSameJVM test will  be a good test of a hard to test
> exception.   I think you need security manager to reproduce and only the
> network server tests run with security manager.  Embedded gets tested
> because network server just makes embedded calls.

OK, I get it now. I made a mistake when trying to get svn to show me
what you committed in 179927. I had the full patch in my sandbox,
updated to 179927 and diffed against PREV. That made it look like you
had committed the whole patch... :( So I could not figure out what you
wanted me to do... Sorry about the confusion.

Using 'find' I can only find one other place where

                throw StandardException.newException( SQLState.SERVICE_DIRECTORY_CREATE_ERROR,
dataDirectory, ioe);

So here ioe (an IOException) is added to the StandardException. But I
think this is wrong, because if you want the ioe to be the "next
execption" it needs to be the SECOND argument. As it stands, the ioe
will be inserted into the vector and not used since the message (as
you pointed out) only takes one arg... 

I'll create the jira issue :)

> As for the funny characters, that is DERBY-285 and on my list to fix
> this weekend so I better go do that now #:)

Not to worry :)


However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup

View raw message