Opinions: exceptions in user oct files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Opinions: exceptions in user oct files

Mike Miller-4
Hi all,

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?

 - 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

Reply | Threaded
Open this post in threaded view
|

Re: Opinions: exceptions in user oct files

Olaf Till-2
On Mon, May 01, 2017 at 01:39:22PM -0700, Mike Miller wrote:
>  - 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 think the latter is better, maybe with the addition that Octave
attempts a core dump.

The thing is that Octave doesn't know the consequences of the cause
for the uncaught exception in user code. If one of the consequences
is, e.g., a memory leak, the faulty user code could eat up the memory
if called in a loop with try-catch.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opinions: exceptions in user oct files

Abhinav Tripathi
In reply to this post by Mike Miller-4


On May 2, 2017 2:09 AM, "Mike Miller" <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Opinions: exceptions in user oct files

John W. Eaton
Administrator
In reply to this post by Olaf Till-2
On 05/02/2017 03:07 AM, Olaf Till wrote:

> On Mon, May 01, 2017 at 01:39:22PM -0700, Mike Miller wrote:
>>  - 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 think the latter is better, maybe with the addition that Octave
> attempts a core dump.
>
> The thing is that Octave doesn't know the consequences of the cause
> for the uncaught exception in user code. If one of the consequences
> is, e.g., a memory leak, the faulty user code could eat up the memory
> if called in a loop with try-catch.

I don't see that it's any worse than an immediate crash because of an
unhandled exception.

If I understand correctly, Mike was suggesting a generic catch block at
the top level, which would then issue an error message and return to the
command prompt.  At that point one could choose to continue or exit.
The error message might say something like "Octave encountered an
unknown exception.  This may be a bug in an external library, or in
Octave itself.  You may wish to save your work and restart Octave."

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Opinions: exceptions in user oct files

Mike Miller-4
On Tue, May 02, 2017 at 15:06:25 -0400, John W. Eaton wrote:

> On 05/02/2017 03:07 AM, Olaf Till wrote:
> > On Mon, May 01, 2017 at 01:39:22PM -0700, Mike Miller wrote:
> > >  - 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 think the latter is better, maybe with the addition that Octave
> > attempts a core dump.
> >
> > The thing is that Octave doesn't know the consequences of the cause
> > for the uncaught exception in user code. If one of the consequences
> > is, e.g., a memory leak, the faulty user code could eat up the memory
> > if called in a loop with try-catch.

Hmm, I'm not sure I agree that the situation is as dire as that. I
expect user code that uses and works with exceptions to be a bit more
well behaved. If an exception is not caught, the stack should unwind and
clean up after itself, Octave will report the error, and execution
should be able to continue normally.

If the user code is indeed faulty and uses bare pointers unsafely,
forgets about allocated memory, or other bad programming practices, that
could eventually lead to memory corruption or overrun, which should
result in a SIGSEGV or SIGBUS. This situation is the same whether
exceptions are involved or not. At that point Octave will handle these
signals the same way it does now, attempt to save the workspace and
exit. I'm not proposing any change to that behavior.

> I don't see that it's any worse than an immediate crash because of an
> unhandled exception.
>
> If I understand correctly, Mike was suggesting a generic catch block at the
> top level, which would then issue an error message and return to the command
> prompt.  At that point one could choose to continue or exit. The error
> message might say something like "Octave encountered an unknown exception.
> This may be a bug in an external library, or in Octave itself.  You may wish
> to save your work and restart Octave."

Yes, that is what I meant. And maybe even a special case for any
std::exception, which is guaranteed to have a what() method that might
help describe the reason.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Opinions: exceptions in user oct files

John W. Eaton
Administrator
On 05/02/2017 10:35 PM, Mike Miller wrote:

> Yes, that is what I meant. And maybe even a special case for any
> std::exception, which is guaranteed to have a what() method that might
> help describe the reason.

I experimented with this a bit and came up with the attached patch.

There may be other places that would need similar treatment.

I also experimented with deriving the octave exceptions (execution,
index, interrupt, and exit) from std::exception, but then realized that
it would probably cause trouble for the interrupt and exit exceptions to
be derived from std::exception.  We might still want to derive the
octave execution and index exceptions from std::exception, however.

jwe


except-diffs.txt (4K) Download Attachment