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 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org