Re: Opinions: exceptions in user oct files

[Abhinav Tripathi]

On May 2, 2017 2:09 AM, "Mike Miller" <address@hidden> wrote:
>
> Hi all,

Hi,

>
> With Octave 4.2, the error handling system has been redone using C++
> exceptions. All errors in Octave are now implemented with a small
> handful of custom exception classes. The interpreter catches this small
> known set of exceptions and reacts accordingly, returning control to the
> user's code or to the interactive prompt.
>
> Other exceptions are not caught and cause the entire Octave interpreter
> to be terminated immediately.
>
> I am interfacing some code that throws exceptions, and every DEFUN ends
> up defining its own try-catch block to handle the exceptions the same
> way, turning them into a call to Octave's error() function.
>
> I am curious what others think about this. What should the policy be
> towards user functions in the form of C++ oct files that may throw
> exceptions?
>

How about allowing the user to register a callback function when an exception occurs,  so that it can be called? Users can register a callback at the start and deregister it at the end. Or to make it more complex, why not wrap it in a callback object whose destructor would automatically ask the interpreter to deregister the callback hence avoiding any issues if a users forgets to deregister the callback?

And/Or how about forcing users to derive all their exception classes from either std::Exception or from some octave version of it and hence force them to override the getmessage or similar function?

Regards,
Abhinav

>  - Should Octave catch any unknown exception object and turn it into a
>    general error message, preventing the interpreter from a hard exit?
>
>  - Or should Octave require that user code not throw any exceptions
>    other than the ones that Octave knows how to handle?
>
> I'm not talking about some sophisticated way to map C++ exception types
> to Octave error IDs, just a fallback mechanism to prevent Octave from
> being killed where possible.
>
> --
> mike
>