Pavel Stehule <stehule@kix.fsv.cvut.cz> 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
programming.
> 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