flipmooooo schrieb:

>
>>Arrrghhh!! It would be a crazy, terrible design to make execution
>>decisions by parsing error text! What if the error text got
>
> changed by
>
>>some minor corrective surgery in a sub-release (this happens!!)
>
> What if
>
>>the firebird.msg file is not in English? The API shelters you
>
> from this
>
>>sort of craziness.
>
>
> No, u don't understand. In the called SP i only respond to things
> that i want to log. It contains alot of updates that can succeed or
> fail. In my main procedure i only eat up my own custom made
> exceptions 'INVALID_ENTRY', 'LOCKED_ENTRY' ... and log them with
> their own given CUSTOM messagetext when they were raised. I use the
> messagetext to get the PK from the table where the excpetion
> occurred logged. So after the whole procedure is completed. When its
> returned to the client side with an exception, it wasn't 1 of mine i
> logged and rollback the transaction. If it succeeded without
> exception if the log is empty all updates where done, if not i'll
> have a list of the rows where some exception occurred and the pk of
> the table that caused it. So i can show detailed info at the
> clientside what went wrong and why.
>
> Greetings,
> Filip Moons

Perhaps you would be better off not throwing exceptions inside SP2 but
return two extra status values (integer: 0=OK, 1=failure, varchar:
custom error message)
Inside SP1 you check for the integer status value and if it is one then
do your logging (and throw an exception or do whatever is needed).

I don't think you *need* an exception at all for your purposes.

Urs