#2921 errcatch fails to catch various errors

[Robert Dodier]

errcatch doesn't catch a syntax error. e.g.

errcatch (parse_string (")abc"));

prints an error message but doesn't yield [] as expected. Probably what's going on is that errcatch catches some specific errors but doesn't catch whatever MREAD-SYNERR is throwing (namely whatever is thrown by THROW-MACSYMA-TOP).

[Rene Hansen]

I am struggeling with the same bug at the moment e.g. :
errcatch(parse_string("Heading="));

Does not give []

[Kris Katterjohn]

I just looked at this a bit.

errcatch needs to catch throws to MACSYMA-QUIT to catch the mentioned parser errors, as well as some other errors (e.g., from the Galois field functions in numth).

It looks like errcatch should also catch throws to ERRORSW as well. The ERRORSW variable controls whether or not some errors just cause a throw to ERRORSW instead of the signaling of a Maxima error.

ERRORSW is bound to T in various places in src and there are various catchers setup in src. ERRORSW is also bound to T while evaluating errcatch forms in the hyperint contrib package.

Currently if something in an errcatch throws to ERRORSW and nothing ever catches it, then errcatch will "catch" this due to the eventual lisp error from a throw to a nonexistent tag (and it will also by default print the error report message about the nonexistent tag from lisp and store that message in Maxima's error variable). If a catcher is setup outside the errcatch, then errcatch will not catch the error. (errcatch should catch this just like it will catch throws to RAT-ERR even if something outside the errcatch would have caught it.)

There are other tags that errcatch could catch, but I don't see any other particularly reasonable ones yet. I don't want to set up a bunch of catchers in errcatch, but I'll still look a bit more.

Anyway, I'll update errcatch to catch these new "errcatch tags".

In the cases where errcatch catches a throw to MACSYMA-QUIT or ERRORSW, errcatch has no info on the error that occurred. In these cases I'll make sure some message is stored in Maxima's error variable stating that errcatch caught an error (so error doesn't have "No error." or some previous error message in it.)

[Stavros Macrakis]

parse_string also gives very peculiar errors:

 parse_string("++");

incorrect syntax: Premature termination of input at $.
rse_string("++");++$

Why on earth is rse_string("++"; part of the error?

[Kris Katterjohn]

From glancing at MREAD-SYNERR I'm guessing that COLUMN is going back too far in *PARSE-WINDOW*. I'll try to also look at that more closely soon too.

[Kris Katterjohn]

The bug where errcatch failed to catch some errors has been fixed by commit [f11cab]. I just stuck with ERRORSW and MACSYMA-QUIT as I described before.

(%i2) errcatch (parse_string ("++"));

incorrect syntax: Premature termination of input at $.
e_string ("++"));++$
                  ^
(%o2) []

(%i3) errcatch (gf_set_data ("wtf"));
`gf_set_data': Field characteristic must be a prime number.
 -- an error.
(%o3) []

(%i4) block ([?errorsw : true], errcatch (log (0)));
(%o4) []

Errors from things like %i2 and %i3 were uncaught by errcatch before. For something like %i4 it was like I described in my previous comment about ERRORSW.

For the other issue that Stavros mentioned regarding error messages, I'll need to look into all of this more because there is another issue. I think my initial guess about COLUMN was correct, but when I started testing I managed to get a lisp error from a bogus comparison (without me changing anything). I don't feel like messing with that right now, but I've made note of these issues and I'll try to look into them further soonish.

[Robert Dodier]

Kris, thanks for working on this problem. For the record, I worked on a similar problem some time ago, and what was able to figure out is in:
https://github.com/maxima-project-on-github/maxima-packages/tree/master/robert-dodier/catchable_syntax_error

You mentioned that error doesn't have a helpful error message afterwards -- I guess I was able to figure out how to put the parser error message into error. It is a minor point.

[Kris Katterjohn]

Hi Robert. Thanks for the comment and the link. Sorry I didn't remember your previous work on that.

Yes, the way I went about this was focusing on errcatch since there were other errors that weren't being caught.

My initial idea was to focus on MREAD-SYNERR itself, which is what you did. I see that your new MREAD-SYNERR calls error, which calls MERROR, and so the error variable gets updated with the actual error message. (In my approach I also call MERROR to get error updated, but I only have a generic error message since I call from errcatch.)

I notice that you do not have stuff like line info in your error messages anymore (which you also mention in a comment). My original idea for changing MREAD-SYNERR was to basically build up a string with the existing info and pass that to MERROR so that the error variable would be updated and errcatch would catch the error. I didn't think about that much and I didn't actually try that before moving on to errcatch itself. I wonder if things like line info are missing from yours because you tried something like that and ran into problems.

[Kris Katterjohn]

Last night I was able to look into the issue that Stavros mentioned and the lisp error I mentioned before.

I have fixes for both: one involving changing a binding in PARSE-STRING so that *PARSE-WINDOW* is updated appropriately in MREAD and the other involves checking for the EOF value in when traversing *PARSE-WINDOW* (this EOF value can come from loading a Maxima file, for example). The lack of EOF checking was causing the bogus comparison I mentioned.

After that I found another lisp error I need to investigate. I hope to have time to look at this more later this week.

[Kris Katterjohn]

I finally got to sit down and take care of these other issues. They've been fixed by commits [1584c5], [c5cadb] and [8ea190].

(%i2) errcatch (parse_string ("++"));

incorrect syntax: Premature termination of input at $.
++$
 ^
(%o2) []

By the way, here was an trivial way to trigger a lisp error under clisp:

(%i1) )
incorrect syntax: Illegal use of delimiter )
)
Maxima encountered a Lisp error:


SYSTEM::FORMAT-TABULATE: argument -1 is not a nonnegative fixnum

This is that other lisp error I mentioned a few days ago, and it's fixed by the last commit listed above.

[Robert Dodier]

Thanks for working on it, Kris!