[idea] onerror, omit 'Func' parameter

[Helgef]

In case the onerror function added to v1.1.29.00 will be added to v2, I'd like to suggest that the 'Func' parameter could be omitted within the callback, just as the 'Callback' parameter for settimer can be omitted within a timer callback.

Cheers.

[lexikos]

To disable the current callback for subsequent errors, reverting to default error dialog behaviour only if and when the first error is intercepted? Why would you ever want to do that?

[Helgef]

Hello

You anticipated the need to turn off a callback, since you added the ability, certainly you cannot expect to have imagined all possible reasons people might want to do it? The suggested option makes it simpler to do so, just as it does for settimer.

What you ask is not what I had in mind, but sure, in a script I might present the user with the option to not show any further error dialogs (by turning off the current callback, enabling another one, eg (e)=>1), and perhaps I'd do so after the first occurance, or maybe after the 37th.

What I actually had in mind, was that I'd might want to set an onerror func at the start of a (probably complex) function, using a closure to clean up in case there was an error. Meaning I do not need to store a reference to the closure in the closure, which reduces the risk that I forget to break circular references.

That being said, I'm not sure I'd actually do this, since an error in an interrupting thread would need to be considered, to avoid premature clean up. For onerror to be used this way, I'd prefer if you could specify the callback to be thread specific, eg, onerror Func, Addremove := 1, ThreadSpecific := 0. Perhaps ThreadSpecific could be: -1 to remove when thread finishes but call from interrupting threads on error, 0 not thread specific, and 1 to only call in the current thread (then remove when thread finishes). I imagine that could be useful, but maybe true / false is enough (i.e., not threadspecific / only call in this thread).

With the other thread in mind, I also think some might find it useful to allow the onerror callback to return a value, indicating that the thread should continue, without displaying the default dialog. Eg, return 0 to call the next function or show the default error dialog, 1 suppress and exit thread, -1 suppress and continue thread (error handled).

Cheers.

[lexikos]

With SetTimer, the timer can be expected to execute at least once. For OnError, you would only be able to use this when an error occurs. If no error occurs, the callback would remain in place, with no way to deregister it without specifying OnError's first parameter.

What you ask is not what I had in mind, but sure, in a script I might present the user with the option to not show any further error dialogs (by turning off the current callback, enabling another one, eg (e)=>1), and perhaps I'd do so after the first occurance, or maybe after the 37th.

This is a good answer to my second question.

What I actually had in mind, was that I'd might want to set an onerror func at the start of a (probably complex) function, using a closure to clean up in case there was an error. Meaning I do not need to store a reference to the closure in the closure, which reduces the risk that I forget to break circular references.

This is what I thought you wanted. Your initial suggestion on its own does not work for this because you would still need a way to remove the callback in the event that the thread completes without error. That means keeping a reference to the callback (or implementing thread-specific callback registration, in which case your initial suggestion would not be needed).

Allowing the thread to continue would require careful revision of all commands (and perhaps other code paths) which raise an error. It is somewhat more complicated than simply calling some callbacks before showing the error dialog.

There's also an expectation that throw, which is equivalent to raising a runtime error (and also causes OnError callbacks to be called), will transfer control to 'catch' or exit the thread. Having execution resume immediately after throw is probably not ideal.

Without the ability to continue the thread, thread-specific OnError callbacks don't seem to offer much more than try-catch. It doesn't seem worth the time, complexity or added code size. There may also be a minor performance cost for thread-exit, which wouldn't necessarily be limited to just threads which have OnError callbacks.

OnError was added basically just for handling errors at the program (not thread or function) level; i.e. replacing or suppressing the error dialog, or performing additional logging.

[Helgef]

you would still need a way to remove the callback in the event that the thread completes without error. That means keeping a reference to the callback

Yes.

Allowing the thread to continue would require careful revision of all commands (and perhaps other code paths) which raise an error. It is somewhat more complicated than simply calling some callbacks before showing the error dialog.

Then I certainly do not like the idea.

OnError was added basically just for handling errors at the program (not thread or function) level; i.e. replacing or suppressing the error dialog, or performing additional logging.

Very good, I'll use it like that then, when needed. (If it will be added to v2 )

Cheers.