octave-maintainers
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]