Re: [Firebird-devel] Parameterized Exceptions

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

Vlad Khorsun wrote:
>>>>> Currently user can't create good exception texts and rely on them,
>>>>> because exceptions generally need more informations. So user need to
>>>>> throw exceptions passing its complete text [exception e1 'Exception ' ||
>>>>> info1 || ' at ' || info2]. This lose the ability to create exception
>>>>> texts and to catch the parameters without parse the formated text.
>>>>>
>>>>> The exceptions are currently encoded in this way:
>>>>> isc_except, <number>,
>>>>> isc_random, <string>
>>>>>
>>>>> I propose to make parameters directly inside user text exceptions, like
>>>>> this:
>>>>> create exception e1 'Exception @1 at @2';
>>>>>
>>>>> This is easy for user, easy for the engine. Does not need metadata
>>>>> extensions and is backward compatible.
>>>>     Why not implement built-in FORMAT function instead ?
>>>>
>>> This does not allow the client (or even in PSQL) to catch the exception
>>> parameters, 
>>    Here i can understand and even agree :) I have a big doubt users will 
>> parse status-vector looking for parameters, however. They will sooner parse 
>> combined text message as they do now ;) 
> 
>     As you already wrote in README.exception_handling :
> 
>     "client library older than 3.0 will not be able to correctly format exceptions 
> raised in this new way".
> 
>     Therefore i ask again to at least think on [optional] ability of server-side 
> formatting of such messages.
> 
It's currently encoded as:
    isc_except, <exception number>,
    isc_formatted_exception, <exception message>, <exception parameters>

Where <exception message> is original exception message, hence it will
be what older clients will show.

Do you mean something as:
    isc_except, <exception number>,
    isc_formatted_exception, <formatted exception message>, <exception
message>, <exception parameters>

Then in this case the client will not need any change because text of
this exception is "@1", and the user still can catch all relevant info.
Seems to work well.

> PS You named new error code as "isc_formatted_exception". Do you see the 
> ability to use it not only for user exceptions ?

I see no mention of "user" in the constant. :-)

> I prefer to see more generic name. 
> Note, this error code is used for formatted string, not for exception itself. 
> 
It's still an exception, it's in the status vector. isc_formatted_string
looks confusing to me, meaning something like error types (and not
codes). But I see no problem to describe it as the feature name
(isc_parameterized_exception).


Adriano