At 03:32 AM 11/08/2004 -0300, you wrote:

>Helen
>
>My example shows that when an user exception is raised, sqlcode = -999.
>Documentation says
>
>5. If user-defined exception is thrown, both SQLCODE and GDSCODE variables
>contain zero
>
>so, IMHO there is a bug, in the implementation, or in the doc.

Yes, if you can reproduce it consistently when reading SQLCODE in a WHEN
MyException block, it's a bug. However, merely picking it up in a WHEN ANY
block does not indicate that a custom exception happened, or that an SQL
exception didn't. SQLCODE -999 is a generic "Firebird error", that is
delivered when an error condition occurs that the engine doesn't know about.

>Also, execution of two WHEN clauses seems not clear to me (I think is a
>bug), if program control flows in a WHEN, must not reach another WHEN.
>Like in a CASE.

No, bad guess!! It not like case. When any exception occurs, execution
proceeds downward and outward. First, it goes to the final part of the
block where the exception occurred. It works its way through the WHEN
blocks there, from top to bottom.
-- If it finds a handler for that exception, it stops looking and executes
that WHEN block.
-- If it doesn't find a handler there, it moves out to the next level of
nesting and looks for a WHEN block in the final part of that enclosing
BEGIN...END block. Again, it works through each WHEN block, looking for a
suitable handler....and so on.
-- Ultimately, if it works its way outward and downward to the final END
statement of the procedure or trigger, and has not found a handler, then
the procedure or trigger ends, the work is undone, and the exception passes
back to the client for handling. So, if the original exception eventually
arrives back at the client, it's all over.
-- In Firebird 1.5, it is also possible to handle an exception by
re-raising it: that is, the WHEN block catches the exception, does
something, and ends by calling EXCEPTION (alone, without an
argument). That pushes execution outward.

/heLen