db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-336) The wrong overload of StandardException::newException() is used in some cases
Date Thu, 09 Jun 2005 18:42:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-336?page=comments#action_12313180 ] 

Dyre Tjeldvoll commented on DERBY-336:
--------------------------------------

Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote in Message-id: <42A2114A.4060508@sbcglobal.net>:
>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.

I've tried to modify NSinSameJVM.java to test this, but it seems impossible! As long as the
test i run in Network mode it is impossible to verify that the Exception is correctly constucted,
because the client only gets an SqlException from the driver. The SqlException only contains
the message constructed on the server so unless the null argument is actually inserted into
the message, the error will not be observable in the client.
In embedded mode it is straight-forward to inspect the EmbedSQLException to verify that it
is correctly constructed.

I am starting to think that this type of error should be detected by the StandardException
class itself. It should not allow adding more arguments than its message string supports,
and not allow null arguments. And perhaps no Throwable args unless it already has a nested
exception. These constraints should be enforced when the StandardException is created, (or
modified).

Case 1 and 2 in my first comment can be detected at compile time by adding dummy versions
of StandardException.newException(...) that match the incorrect usage, but trigger a compilation
error (by throwing an unhandled exception). Unfortunately this will also flag Case 3 as an
error, making things more complicated. Maybe another (legal) overload can fix this...

> The wrong overload of StandardException::newException() is used in some cases
> -----------------------------------------------------------------------------
>
>          Key: DERBY-336
>          URL: http://issues.apache.org/jira/browse/DERBY-336
>      Project: Derby
>         Type: Bug
>  Environment: Any
>     Reporter: Dyre Tjeldvoll
>     Assignee: Dyre Tjeldvoll
>     Priority: Trivial

>
> When looking at DERBY-128 it became clear that the wrong overload of StandardException::newException()
was used when reporting
> SQLState.SERVICE_DIRECTORY_CREATE_ERROR. The message string only takes one parameter
so only one additional parameter (other than Throwable) should be used:
> PersistentServiceImpl.java:676
>                             throw StandardException.newException(SQLState.SERVICE_DIRECTORY_CREATE_ERROR,
>                                                                  serviceDirectory, null);
> // Calls StandardException.newException(String, Object, Object)
> // Should call StandardException.newException(String, Object)? Or StandardException.newException(String,
Throwable, Object)? With the IOException as  
> // Throwable?
> PersistentServiceImpl.java:692
>         throw StandardException.newException(SQLState.SERVICE_DIRECTORY_CREATE_ERROR,
name, t);
> // Calls StandardException.newException(String, Object, Object)
> // Should call StandardException.newException(String, Throwable, Object)?
> BaseDataFileFactory.java:279
>                 throw StandardException.newException( SQLState.SERVICE_DIRECTORY_CREATE_ERROR,
dataDirectory, ioe);
> // Calls StandardException.newException(String, Object, Object)
> // Should call StandardException.newException(String, Throwable, Object)?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message