[ http://issues.apache.org/jira/browse/DERBY-336?page=comments#action_12313180 ]
Dyre Tjeldvoll commented on DERBY-336: -------------------------------------- Kathey Marsden <[EMAIL PROTECTED]> wrote in Message-id: <[EMAIL PROTECTED]>: >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
