[
https://issues.apache.org/jira/browse/DERBY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659007#action_12659007
]
Myrna van Lunteren commented on DERBY-1465:
-------------------------------------------
I'm still looking at the previous comment, but the last comment throws me for a
loop.
In the latest patch, using the exceptionHolder array as suggested and not using
a global variable to hold the exception, we do not know what kind of exception
it is in the start() method. So we can't actually check for the BindException
class in the test, all we have there is a java.lang.Exception.
When we use a global variable (we used runtimeException in earlier patches),
and assign the Exception underlying the PrivilegedActionException at the top of
the privilegedException block to it, then the cause of the Exception, at least
for IOExceptions (i.e. in the case of the java.net.BindException the test is
forcing) is saved off. Like so:
} catch (PrivilegedActionException e) {
Exception e1 = e.getException();
runtimeException = e1;
I could reinstate the runtimeException, and in the start() method do some
tomfoolery like:
if (runtimeException != null)
exceptionHolder[0] = runtimeException;
else
exceptionHolder[0] = e;
Then I can check for the bindException instance in the test...But that's
reintroducing the global variable...
What is the better approach?
I do like the fact that with the global variable you can actually check for
IOExceptions in the test (and thus app) code, gives more info/control...But
maybe it's enough to have an Exception?
> NetworkServerControl.start() should throw an exception and not just print
> exceptions if the server fails to start
> --------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1465
> URL: https://issues.apache.org/jira/browse/DERBY-1465
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Priority: Minor
> Attachments: DERBY-1465.diff3, DERBY-1465.diff4, DERBY-1465.diff5,
> DERBY-1465.diff6, DERBY-1465.diff7, DERBY-1465_diff.txt, DERBY-1465_diff.txt,
> DERBY-1465_stat.txt, DERBY-1465_stat.txt, releaseNote.html, releaseNote.html,
> releaseNote.html
>
>
> NetworkServerControl.start() will not throw an exception if another server
> is already running on the same port. I am not sure but think perhaps this
> was changed at one point to accomodate the derby.drda.startNetworkServer
> property so that the embedded server could continue to boot even if the
> network server failed to start, but I think this is wrong for normal usage.
> http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
