Re: [Firebird-devel] Parameterized Exceptions

[Dmitry Y. <fir...@ya...>]

Adriano,

> 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.

Valid point, thanks.

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

I'm against the flexibility which is added just for the sake of 
flexibility. We need to address particular user needs, preferably 
expressed publicly (e.g. via the tracker) and by more than a single 
person. I don't think we should develop a LEGO thingy to please the 
every possible fantasy of our users ;-)

> 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.

We have exactly the same situation in the API. Users may need various 
information being available during prepare. We provide some subset via 
XSQLDA, but the rest should be retrieved via isc_dsql_sql_info(). In 
many cases it means an extra rountrip. And IMO this is perfectly okay. I 
don't think we should deliver (in advance) whatever information the 
client may wish.

And I'm still not convinced regarding its usefulness, sorry.


Dmitry