Re: Major revision for error handling in the interpreter

[John W. Eaton]

On 10/7/19 7:11 AM, Pantxo wrote:
> Pantxo wrote
> > octave:1> plot (1:10); print /tmp/toto.eps
> > Input file "/tmp/oct-g6hKlo.eps" is not EPSF.
> > octave:2> fatal: caught signal Erreur de segmentation -- stopping
> > myself...
> > Erreur de segmentation
> >
> > Sent from:
> > https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html
>
> Then if I call "error" again in the interpreter thread (instead of
> rethrowing the exception), I can prevent the crash, but the error message is
> lost and the error is interpreted as a parse error (as it used to be):
>
> diff -r 9e526393d80a libgui/graphics/GLCanvas.cc
> --- a/libgui/graphics/GLCanvas.cc       Sun Oct 06 22:25:36 2019 +0200
> +++ b/libgui/graphics/GLCanvas.cc       Mon Oct 07 13:06:35 2019 +0200
> @@ -183,11 +183,11 @@
>           catch (octave::execution_exception& e)
>             {
>               emit interpreter_event
> -              ([] (void)
> +              ([e] (void)
>                  {
>                    // INTERPRETER THREAD
>   
> -                 std::rethrow_exception (std::current_exception ());
> +                 error ("%s", e.message ().c_str ());
>                  });
>             }
>
> With this change I obtain:
>
> octave:1> plot (1:10); print /tmp/toto.eps
> Input file "/tmp/oct-X5l7zO.eps" is not EPSF.
> octave:2> error: parse error
> octave:2>
>
> So I guess there is something better we can do so that at least the original
> error message isn't lost, and we ideally avoid this erroneous "parse error"
> message.

I pushed the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/458adc344819

It seems to avoid the crash for me (thanks for the tip) and doesn't 
change errors in the event manager callback functions to be labeled as 
parse errors.

jwe