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 ;) But i agree, it have its own pluses.
> 
>> and to define messages right in the exception. 
> 
>     This is i don't understand.
> 
If user need to use FORMAT, it will need to pass again the exception
template text. The text in the exception (metadata) looses it meaning.

>> FORMAT is useful, and should format the same way exceptions are formated, 
> 
I had a prototype for FORMAT, so I'll probably do it too.

> 
> PS I think we should not use isc_random with such messages and tweak the engine.
> 
Why not? I think general usage of isc_random is ok. It may be used
everywhere exceptions are generated but doesn't need (or can't - think
on plugins) insert messages in firebird.msg.

> PPS How do you going to handle case when passed arguments not corresponds to the
>     placeholders in text message ?
> 
The @N will be maintained in the text. It would be unwise to replace an
user exception by another one.


Adriano