FR: have the errors as an internal errortable

[Bart Pietercil]

On 25-sep-07, at 09:46, Ivan Smahin wrote:

> Hello Bart,
>
> Monday, September 24, 2007, 3:47:28 PM, you wrote:
>
>>>> Some thoughts about error reporting
>>>
>>>> As it stands now there is no way of saying that our errorProcedure
>>>> should ALWAYS be used, is there ? Maybe I should explain:
>>>> Now we need to explicitly call in an exception block of a stored
>>>> procedure the errorProcedure in order to trigger it. I think it  
>>>> would
>>>> be better if a developer would be able to specify that the
>>>> errorProcedure should always be used when an error occurs (not only
>>>> when called from a stored procedure but also when a query launched
>>>> through an API generates an error. This way error handling would be
>>>> as close as possible to the engine and as close as possible to the
>>>> developer (the one making the mistakes :-)) and logging of what  
>>>> went
>>>> wrong would be a lot easier.
>>>
>>> Add it please as feature request.
>>> I  see  - you want to get something like a hook to register own
>>> "event"
>>> handlers. Particularly error handler. Need to think.
>
>> Right: set ErrorHook = call myCustomErrorHandler()
>
> Well, we wonder - is it something you see somewhere or just a dream?

This is the mechanism used by for instance Director. They implemented  
what they called 'primitifs' that you could use to change the default  
calling chain.
so you could say set the mouseupscript = 'dosomethingHandler'.
This ment that when the OS passes a mouseup to Director BEFORE  
anything else doSomethingHandler was executed AND THEN the normal  
calling chain continued unless you specified 'DontPassEvent'.

Something similar (no exactly the same) you could do with the  
alerthook where you could override default alerts with your own  
explanations

set the alerthook = 'myAlertHandler'

when you wanted to fall back on the default behaviour you just set  
the hook or primitif to empty

set the alerthook = ''


>
> 1.  It is relatively easy to get such feature for any exception raised
> in any stored procedure. Set some global handler (any exception raised
> by any operation) is more difficult task.

Probably, the advantage of course is that the developer can build his  
own errorreporting inside the engine and all ADK calls will use his  
own system. Otherwise for every call from an ADK he will need to make  
a stored procedure to be able to use his own error reporting

>
> 2.  Such  handler makes the database looks like a box which eats any
> exception  raised  inside  one.  Assume  I  get your database for some
> purposes and open it in vStudio. Perform some query which is obviously
> should   raise   an   exception  (some parser error) - but see nothing
> because of some handler,
> which  is  set  by  someone. Probably it should be 'set handler'  
> per session?
>

not necessarily. If you implement like a primitif (see higher) the  
chain would be: check errorhook if hook is set, if hook is set  
execute hookProcedure, when hookProcedure is finished (,if  
@errorCallChain = False  abort the rest of error chain if  
@errorCallChain is not set or true continue with normal error  
handling. This way VStudio can still behave normally . It is up to  
the developer to decide whether he wants a closed box ( @  
errorCallChain = False) or the normal behaviour (@ errorCallChain =  
True or maybe Nil). He can influence this by setting the  
errorCallChain to false if he wants his box to be closed. This looks  
indeed as a session variable
>
> On the other hand - triggers are kind of event handlers.
>
> I mean - we need to think of event handlers in the wide sense.
> Something like
> "trigger on any error"
> "trigger on error xxxxx"
> "trigger on insert in table t1"
> ...
if the custom ErrorHandler does not handle an error the error would  
'fall through' and if errorCallChain is not set would be picked up by  
the normal error reporting

Bart