[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Major revision for error handling in the interpreter
From: |
Pantxo |
Subject: |
Re: Major revision for error handling in the interpreter |
Date: |
Mon, 7 Oct 2019 06:11:38 -0500 (CDT) |
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.
Pantxo
--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html