[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Kudos to jwe on exception handling
From: |
John W. Eaton |
Subject: |
Re: Kudos to jwe on exception handling |
Date: |
Thu, 29 Oct 2015 16:30:06 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 |
On 10/06/2015 04:07 PM, Rik wrote:
All,
I wanted to give a shout out to jwe who has been doing exceptional (pun
intended) work transitioning the core away from using the global variable
error_state. The implementation began in Darmstadt just 2 weeks ago and if
I grep through libinterp for "error_state" from that time I find 1671
instances. Today, the number is down to 496. 70% of the instances have
been removed, and most of them it seems in just the last day. Hip Hip Hurray!
Thanks, and sorry I stalled out for the last three weeks.
I noticed a few problems along the way. The first, having to do with
wrong-type-argument errors, was already discussed here in the "Using
exceptions in the core" thread. Another is that for code like this
function f () error ("foobar"); end
function g () 1:f:f; end
g ()
you will see the following errors:
error: foobar
error: called from
f at line 1 column 20
g at line 1 column 15
error: invalid limit value in colon expression
error: called from
g at line 1 column 15
Note the duplicate stack trace info. This is also a problem in 4.0.0,
so it is not related to the latest exception handling changes. I
introduced this behavior when I made the error function display the
stack trace immediately. I've just checked in a change to correct this
problem:
http://hg.savannah.gnu.org/hgweb/octave/rev/e0e2c2ce7e94
The idea is to store the stack trace info in the exception object that
is thrown by error, and then display it just before displaying the next
prompt. I don't really like the structure yet, but this change solves
the immediate problem. I'd prefer to store information about the stack
in the exception object instead of just storing a string. But for now I
think this works.
It would probably also be good to try to design a good hierarchy of
classes to use for exception handling, possibly derived from the
standard library exceptions.
Next I'll keep working on removing more uses of error_state and fixing
problems that I've introduced (for example, the problems with glob).
jwe