Exceptions checking

[Ivan Smahin]

Hello Bart,

Friday, September 12, 2008, 12:07:50 PM, you wrote:

> Hi List, Ruslan

> while looking and playing with the exceptions some questions remain:

> 1) Can I use the <description> in Stored Procedures instead of the  
> numbers (much clearer) as they are defined in the sql_errors.xml and  
> kernel_errors.xml.

Yes, you can use both.

> 2) Do I understand correctly that both files are used in exception  
> checking ?

Right.

> If yes then why are there 2 files instead of 1 with all the exceptions ?

Because of planning to split API and SQL ways in the future.

> 3) Do I understand correctly that we can edit the <GROUP name="User- 
defined errors">> in order to raise our own exceptions (as long as we  
> stay in the predefined range)

No, you could not add new states in this way. Instead you should
raise something like 0x50001, 0x50002 ...
Sure you can do following inside the sp:

DECLARE MY_STATE as long;
SET MY_STATE = 0x50001;
...

RAISE MY_STATE;
...

> Maybe as a feature request there could be a third file named  
> user_defined_errors.xml that would need to have the same structure as
> the other two.
> Difference would be that Paradigma can  while updating replace the two
> 'standard' files without overwriting the user_defined_errors.xml.

Well, actually that XMLs play two roles
1. We use them for generating some C++ sources for "error" processing.
2. You could use it for getting some explanations.

Having one "user-Defined.xml" we should processing it in runtime.

On the other hand - there is a way to define own "states" inside SPs
or tables. It is something like special for particular project states.
It could not be common ones.

> 4) Do I understand correctly that in order to be used these files HAVE
> to reside in the vresources directory.

Yes.

> 5) Can a stored procedure return the <message> and <comments> xml  
> nodes to the calling client ?


>   If YES how ?

> If NO  we will return the error to the calling client (in our case php)

> a) can we do this like this:

> EXCEPTION
>      WHEN ERR_CONSTRAINT_UNIQUE_VIOLATION THEN
>          return  ERR_CONSTRAINT_UNIQUE_VIOLATION
> END;

Look, you are catching the exception and going to pass it outside.
Probably you should just let it go self? In this case client will get
an exception as usual.

-- 
Best regards,
Ivan Smahin 
Senior Software Engineer
Paradigma Software, Inc
Valentina - The Ultra-Fast Database
http://www.valentina-db.com