Re: [Firebird-devel] Parameterized Exceptions

[Adriano d. S. F. <adr...@gm...>]

Dmitry Yemanov wrote:
> All,
> 
> I'll try to comment to a few different messages at once. I'm not sure I 
> remember all the proposed details (they're somewhat hidden inside the 
> flame wars), so I'll be basically expressing my own opinion.
> 
> Checking the client library version looks like a good solution, but it's 
> not related to the things being discussed at all. This way we may speak 
> about sending whatever GDS error code as isc_random if the client 
> msg-version mismatches the server one. This resolves the backward 
> compatibility for all possible new error codes as a whole. Implementing 
> this just for the parametrized exceptions makes very little sense to me.
> 
Exceptions are not meant to be always formatted by the client library,
so changing codes depending on client version is non sense for me.
You'll kill applications that parse the status vector to try to
understand specific situations.

> The currently existing exception functionality must preserve the 
> isc_except error code with its format (using isc_random).
> 
Of course.

> The formatted exception may either reuse the same error code and send 
> the already formatted error message to the client or use the new 
> isc_formatted_exception error code with the format text and the 
> arguments and leave it up to the client to format the message. The 
> answer depends on whether we care about older clients handling the 
> exceptions thrown in a new way or not.
> 
This is the two ways I had did, and I can say the later is much better.
It just works without client support.

> Sending the formatted exception in both ways looks like an overkill to 
> me. I don't buy the argument of using gds__msg_lookup() to get the 
> message template text, as I don't know anyone needing this (and I'm not 
> sure this routine is ever documented).

I never understand why this project don't want flexibility to the user.
Can you explain? :-)

Adding the template string does not add extra logic to the application.
It just must start getting the arguments one element next. Since this is
new feature and nobody know how to use it without read the
documentation, there is nothing wrong with this.

Additional string in the status vector will not make the application
slower or consume all it memory.

On the other hand, if the user want the string it will need to catch the
error number and issue a query against rdb$exceptions. Considering that
the original exception may even be thrown when starting a transaction
(in a trigger), user need to start a transaction just for this. What a
amount of work to do after an exception because the FB devs didn't want
to include an useful string for nothing.

This string may be important, just like exception name and arguments. It
may be logged and searched for. It may be used to implement localization
of exceptions by texts on the client. You may say these things can be
implemented in different ways and I agree, but I see no sense in hide a
piece of information that may be difficult (under the circumstances of
an exception to be retrieved).

There may be problem with length of status vectors, but I'd rather fix
that. It was big problem for Java exceptions with they long stack
traces. Looks like recently the internal limit has been increased or
some architecture difference has changed. It showed truncated exception
messages under Windows SS and worked correctly in Linux SC.


Adriano