Re: [Firebird-devel] Parameterized Exceptions

[Vlad K. <hv...@us...>]

> Vlad Khorsun wrote:
>>> I did this changed, 
>> 
>>     In README.exception_handling you wrote :
>> 
>> =============
>> The status vector is generated using that codes combination:
>> isc_except, <exception number>,
>>     isc_formatted_exception, <formatted exception message>,
>>     <defined exception message>, <exception parameters>
>> 
>> Since new error code (isc_formatted_exception) is used, it's necessary that the client is v3.0
>> or at least uses firebird.msg from v3.0 so that it can translate the status vector to string.
>> 
>> =============
>> 
>>     Why include both <formatted exception message> and <defined exception message> ? 
>> Why not use isc_random for <formatted exception message> ? 
>> 
> You first insisted on use something different than isc_random. Now you
> insist the contrary? Just nitpicking or what?

    First, where do you see i *insist* on something ? Second, i think old thing should
be done as before, so - isc_random for old style error mesage, new error code for
new style error message.

> Both are included because the original message template may be
> interesting to the client code as well the parameters.

    It seems overkill for me to include both messages into same status-vector.
Old client can't understand new (defined) message and new client not needed old 
(formatted) message.

>>> it looks well, but since new code is introduced the
>>> older clients needs at least v3 firebird.msg. 
>> 
>>     Do you think that someone will update firebird.msg but not fbclient.dll ? 
>> What benefit for users of old client your last commit gives ?
>> 
> Features that depend on updated client requires client updation or may
> not function totally correctly. 

    What about old feature - exception without parameters ? Seems it works as 
before, with isc_random ?

> *Any* new error message requires update
> of firebird.msg in the client, if you not know.

    Therefore i offers way to preserve backward compatibility, if you know what is it.

    Could you answer on my simple question : what benefit for users of old client 
your last commit gives ? Why it is better than your previous commit ? Is it make
old clients more happy ? Maybe new client have some additional benefits ?

> Now the thing just works (of course, depending on message in
> firebird.msg). Any version since 2.0 may display the error message. No
> new semantics is inserted in the status vector, just ordinary parameters
> so any tool have no problem to understand it.

    Dependancy on firebird.msg makes all this efforts NULL. So i see no sence to do 
it in the way you did.

>>> If we don't want this, the
>>> message shall be encoded with isc_random. Currently, no special handling
>>> for isc_formatted_exception has necessary.
>>>
>>> We can also add isc_formatted_exception to firebird.msg of 2.0, 2.1 and
>>> 2.5 now, so next versions will be able to understand these exceptions.
>>> This look the better way to go for me.

    We never did it before. And i don't think it is good to leave gap in error messages
numbers. Also it will add nothing to the currently installed clients.

>>     Sometime you make me think that you read only what you want to read, not
>> what others wrote :( Does you read my idea about syntax support ? Does you read 
>> another idea about to fill status-vector depending of client version ?
>> 
> I will not store isc_random in the status vector if client is < 3.0 and
> isc_formatted_exception when >= 3.0. 

    Why ? Probably you have really good argument to not do it ? I want to know it too.
I do not insist on it, just want to know what you know.

> It's not how things should work.

    Surely, you and only you know how things should work :)

Regards,
Vlad