Pavel Stehule <[EMAIL PROTECTED]> writes:
> Next problem, visibility custom exceptions. When I define exception 
> variable I can't rethrown exceptions outside block when is defined. What 
> is outside - some custom exception?

I don't think this is an issue.  A custom exception is really just a
name for a SQLSTATE value, so you can throw it in any case.  An outer
block that does not know that name can only catch it as WHEN OTHERS,
but so what?

I would also expect that matching is by SQLSTATE, that is if I write

        DECLARE foo EXCEPTION = '12345';
        RAISE ERROR foo, ...;

then some outer block written as

        DECLARE bar EXCEPTION = '12345';
        EXCEPTION WHEN bar THEN ...

would catch this error.

> disadvantage - I have to define format string everywhere where I wont to 
> raise exception.

Why is that a disadvantage?  You should not be able to throw an error
without providing a useful message --- that's just basic good

> From OOP view exception is object. But I need define more properties than 
> one. SQLSTATE is only first, second message, level, meybe next

I think we are better off defining exception names as SQLSTATEs and
nothing else.  That's essentially how we have done it in the backend
code and it has worked well over a very large body of code.  You are
arguing for a less flexible definition on the basis of nothing more
than a vague appeal to "OOP principles".  You have neither stated
exactly which principles nor exactly why they dictate this choice,
so I see nothing convincing in your argument.

> I think so we need more then one exception level. I can use 
> user's exception for easy way of write to log.

Well, can we get away with making the syntax be

        RAISE level [ exception_name , ] format_string [ , parameters ] ;

where "level" is one of the already-defined level keywords?  Normally
I would think that this would be unacceptably ambiguous, but as long as
the exception_name is constrained to be either a built-in or previously
defined exception name, this is probably workable from a syntactic point
of view.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to