Thanks Rick, for the pointers and ideas.
In the code block which you are studying, the message formatting logic responds
to the ShutdownException by falling through to its last chance handler. Do you
think it should do something else?
No, I don't propose to change its behavior, just to understand it.
In the context of DERBY-6773, Abhinav and I have been studying whether
we can refactor MessageService.getLocalizedMessage() so that it
resides in the shared area of the code and can be bound into both
the client and server jars.
The intent of the refactoring is to gather all the code which knows
about packing exceptions into network messages (SQLERRMC blocks) and
then de-packing them on the other side into a single class, rather
than the current situation where the code is rather spread about.
And the code just above the code I quoted yesterday is directly
dependent on other code in the networking classes that we're also
proposing to refactor; it encodes message arguments with special delimiters:
char [] sqlerrmc_chars = sqlerrmc.toCharArray();
int numArgs = 0, lastSepIdx = -1; // last separator
index
for (int i = 0; i < sqlerrmc_chars.length; i++)
{
if (sqlerrmc_chars[i] == 20) // separator
{
numArgs++;
lastSepIdx = i;
}
}
That's the code I'd like to be able to call directly from the client libraries.
The dependence on ShutdownException is the only thing (that I can tell)
which is requiring these two methods to be in the engine jar; otherwise
they could clearly be in the shared code.
But to accomplish that, we'll also need to refactor ShutdownException
so that it is part of the shared code, too. Which is a tiny change, but
is still a widening of our proposal.
I was searching for ways to avoid it, e.g., by having getLocalizedMessage()
throw the ShutdownException and have its caller catch and handle it, but
that's not a 1-line change to the code, either.
I guess I was sort of hoping somebody might say:
"Oh! That's dead code! It was in there as early scaffolding, and
can simply be removed."
But I don't believe that to be the case, and will stop hoping for that.
:)
bryan
