Add "trap" keyword for Go-like error handling #4051

d-torrance · 2025-12-04T14:05:27Z

This is an alternative to #4047 that may address @mahrud's concerns. Rather than touching try, we add a new keyword attempt that returns a pair (val, err) (much like Go), where val is the value of the code and err is null if no error occurred, and otherwise val is null and err is an instance of a new Error type with information about the error that occurred .

i1 : attempt 5

o1 = (5, )

o1 : Sequence

i2 : attempt 1/0

o2 = (, Error{"message" => division by zero})
              "position" => stdio:2:8-2:11

o2 : Sequence

M2/Macaulay2/packages/Cremona.m2

mahrud · 2025-12-04T16:39:09Z

I really like this solution!

seangrate · 2025-12-04T20:06:01Z

This seems like a good approach. Hopefully at some point, we can also build in some sort of error types so that we can check for particular errors by their types as opposed to their messages.

d-torrance · 2025-12-04T20:12:12Z

That sounds like a good idea!

pzinn · 2025-12-05T00:59:29Z

what I don't understand is, the output of attempt is a pair, but either the first or the second element of the pair is null? what's the point? one might as well test if output is an instance of Error

pzinn · 2025-12-05T01:03:08Z

the location of the error is different than in the usual error message. is that intentional?

i1 : 1/0
stdio:1:1:(3): error: division by zero

i2 : attempt(1/0)

o2 = (, Error{"message" => division by zero})
              "position" => stdio:2:8-2:11

o2 : Sequence

(it may not be obvious, but in the example the first error point to / whereas the second points to 1/0)

pzinn · 2025-12-05T01:10:29Z

This location doesn't seem right either:

i1 : attempt(1/a)

o1 = (, Error{"message" => no method for binary operator / applied to objects:})
                                       1 (of class ZZ)
                                 /     a (of class Symbol)
              "position" => ../../Macaulay2/m2/robust.m2:101:25-101:66

o1 : Sequence

d-torrance · 2025-12-05T01:45:51Z

what I don't understand is, the output of attempt is a pair, but either the first or the second element of the pair is null? what's the point? one might as well test if output is an instance of Error

That's a good point. I was basically just copying the Go syntax that Mahrud pointed out in the other PR. Also, in an earlier draft, the second element was a string, not an Error object, so it was necessary then.

d-torrance · 2025-12-05T01:52:09Z

As for the file positions, as I recall, errors originally all start out with dummyPosition and then get updated in various places, right? I think attempt is grabbing it a little later than it would have gotten printed if printing wasn't suppressed by tryEval, so maybe the position was updated a bit more in the meantime?

mahrud · 2025-12-05T05:40:18Z

what I don't understand is, the output of attempt is a pair, but either the first or the second element of the pair is null? what's the point? one might as well test if output is an instance of Error

Strictly speaking, in Go the return value is always of the expected type, so attempt 1/0 should return (0, Error{...}) or something like that, but currently there's just no output. But even for us, because of type consistency this is more readable:

(inv, err) := attempt inverse n
if err =!= null then error("oops: ", err#"message")

than a situation where the return value has different types in each branch:

ret := attempt inverse n
if not instance(ret, Error) then inv := ret else error("oops: ", ret#"message")

Also, what if you're writing an error-handling related function that needs to return an error? You need to separate the legitimate output Error object from the error that may have occurred in the process :)

pzinn · 2025-12-07T21:55:17Z

I stand by my original point.

antonleykin

The two ideas are good.
The second (proposed by @seangrate) to have an Error type.
The original idea to "capture message of error" (due to @d-torrance) via attempt (returning it, not storing, proposed by @mahrud).

Returning one thing---either "result" or Error---would be more natural, since our language is not statically typed (e.g., the type of the "result" is unknown anyway).

antonleykin · 2025-12-08T11:24:06Z

M2/Macaulay2/d/evaluate.d

+    else (
+	when r
+	is err:Error do seq(nullE, toExpr(err))
+	else seq(r, nullE))); -- shouldn't happen


This shouldn't happen, unless the code fabricates it's own Error. I don't think we should let attempt output user-fabricated stuff.

Makes sense. I've replaced this with an error.

antonleykin · 2025-12-08T11:33:55Z

M2/Macaulay2/packages/Macaulay2Doc/ov_debugging.m2

+    attempt c
+  Description
+    Text
+      The code @VAR "c"@ is evaluated and a sequence containing two elements


Emphasize that this is a keywork in the language, not a method. One could mentally parse (attempt 1)/0.
Perhaps give more examples: what would attempt 1/2; 1/0 give?

Documentation expanded

d-torrance · 2025-12-08T13:08:23Z

@antonleykin - I think I've addressed your comments. attempt now returns a single element, either the value of the evaluated code or an Error object.

mahrud · 2025-12-09T04:34:31Z

I would encourage you to reevaluate this decision. Here are a few dangers of this paradigm:

If a helper function constructMyError legitimately returns an Error object (we have LOTS of these helpers in Core), it's impossible to detect from err := attempt constructMyError(...) if err is a legitimate output or if constructMyError itself failed. We need Core to be robust, so I wouldn't use attempt there with this implementation.
Since error checking is less explicit, it's easy for users to forget to check for errors and only later end up with confusing type errors like dim myFunc() giving error: no method found for applying dim to: argument : Error {...} (of class Error)
Even worse, since Error inherits from hash tables, a caller can accidentally treat the output as input to a function that accepts a hash table and consequently mask the error. Here is an explicit example of this:

f := M -> attempt apply(codim M, i -> i^2);
# f(ZZ^100)      -- gives #{}         which is 0
# f((ZZ[x])^100) -- gives #Error{...} which is 2

If you're going through the trouble of adding a new keyword, I'd like it to be robust and future proof, especially for MPI or RPC type applications.

pzinn · 2025-12-09T05:26:28Z

I would encourage you to reevaluate this decision. Here are a few dangers of this paradigm:

If a helper function constructMyError legitimately returns an Error object (we have LOTS of these helpers in Core), it's impossible to detect from err := attempt constructMyError(...) if err is a legitimate output or if constructMyError itself failed. We need Core to be robust, so I wouldn't use attempt there with this implementation.

this I don't understand at all. There seems to be a basic confusion here. These Error types are produced by the interpreter itself or at the level M2 level by calling error, not by creating an error manually. If we were to do what you suggest that would be a totally different usage which would require a separate discussion -- and a complete rewrite of this PR anyway.

Even worse, since Error inherits from hash tables, a caller can accidentally treat the output as input to a function that accepts a hash table and consequently mask the error. Here is an explicit example of this:
f := M -> attempt apply(codim M, i -> i^2);
# f(ZZ^100)      -- gives #{}         which is 0
# f((ZZ[x])^100) -- gives #Error{...} which is 2

well, if you're going to write attempt, that means you're expecting an error, so you should test for it, otherwise you probably shouldn't use attempt in the first place.
That being said, I agree that Error probably shouldn't inherit from HashTable; instead, just like Dictionary, it should be its own type.

mahrud · 2025-12-09T20:35:44Z

There seems to be a basic confusion here. These Error types are produced by the interpreter itself or at the level M2 level by calling error, not by creating an error manually. If we were to do what you suggest that would be a totally different usage which would require a separate discussion

Why shouldn't error objects be produced at the top-level? Is something preventing it in this proposal? There is a huge upside, as @seangrate suggested above, in allowing custom subtypes inheriting from Error so that error checking looks more like if instance(err, RingError) ... rather than if err#"message" == "incorrect ring" .... Otherwise why bother with a new type at all?

We currently don't have an Error type, but once it exists I guarantee this PR isn't going to be the end of it. Soon we'll have extensions like Python error types and Flint error types and use it with hooks and threads and loads more that we can't imagine now. (Side note: @d-torrance if err is an instance of Error then probably error err should produce an error with that location and message)

well, if you're going to write attempt, that means you're expecting an error, so you should test for it, otherwise you probably shouldn't use attempt in the first place.

Mistakes like this will sneak in, either by people treating attempt like try or just mistakes in the programming where there are multiple branches and you forget to check if the output is an error in one branch.

More generally, I'm just surprised that we're going with a syntax like this:

c := attempt codim M;
if instance(c, Error) then
if c#"message" == "codim: expected an affine ring (consider Generic=>true to work over QQ"
then c = planZZ(M)
else error "unexpected module"

d-torrance · 2025-12-09T20:41:47Z

I'm convinced by @mahrud's arguments and prefer the Go-style two-element output.

pzinn · 2025-12-09T20:52:24Z

Why shouldn't error objects be produced at the top-level? Is something preventing it in this proposal? There is a huge upside, as @seangrate suggested above, in allowing custom subtypes inheriting from Error so that error checking looks more like if instance(err, RingError) ... rather than if err#"message" == "incorrect ring" .... Otherwise why bother with a new type at all?

because that simply wouldn't work in the current setting. what would happen if you called your function that outputs an error your way without attempt? in fact, what's the role of attempt then? As I said, if you want to go this route, then we should scrap this PR and start from scratch with a completely different design.

There absolutely should be subtypes, but this is irrelevant to the point I'm making.
I'm simply suggesting Error be its own "root" type.

d-torrance · 2025-12-10T03:25:03Z

I went back to the Go-style output and also added some basic support for subclassing of Error:

i1 : MyError = new SelfInitializingType of Error;

i2 : MyError "foo"

o2 = MyError{"message" => foo}

o2 : MyError

i3 : error o2
stdio:3:5:(3): error: foo

i4 : attempt error o2

o4 = (, MyError{"message" => foo                            })
                "position" => ../m2/debugging.m2:21:22-21:75

o4 : Sequence

mahrud · 2025-12-10T04:31:48Z

Looks like the error

"position" => ../m2/debugging.m2:21:22-21:75

is pointing to this line:

error Error := err -> olderror new class err from processArgs err#"message"

No obligation to fix this in this PR, but obviously the location should point somewhere more appropriate. There are probably multiple ways to fix it (e.g. maybe moving error(Error) to the interpreter?), but one of my hopes from the attempt keyword is to fix these spurious error layers: #2568.

pzinn · 2025-12-10T06:18:46Z

I understand less and less the logic. Now one can create Error objects at the M2 level, which are then fed to error, which at the d level proceeds to discard that Error object, only keeping track of the message, and creates a new Error object out of it... ??

mahrud · 2025-12-10T07:29:13Z

The point of object oriented error handling is that instead of interrupting the computation, an error object is created to help the subsequent code resolve it and proceed without interruption. But there may be errors objects which can't be handled, so there should be a way to force an interrupt so that the user can intervene. This is where error(Error) comes in, to simplify this:

(c, err) := attempt codim M;
if instance(err, Error) then
if instance(err, RingError)
then c = planZZ M
else error("unexpected error: " | err#"message" | " at " | err#"position")

into this:

(c, err) := attempt codim M;
if instance(err, Error) then
if instance(err, RingError)
then c = planZZ M
else error(err) -- the original message and position are returned

Also bump to version 0.2 and start a changelog

Now takes a single input (the object to print) and leaves the formatting of the message to the caller. Also renamed to RobustPrintNetMethod so we can also have RobustPrintSringMethod (which we'll use for arbitrary errors)

mahrud · 2025-12-23T17:09:24Z

I presume this is just a rebase?

d-torrance · 2025-12-23T17:10:25Z

Yup -- fixing the conflicct

mahrud · 2025-12-24T15:30:23Z

@antonleykin @pzinn @mikestillman any objections to merging this for now, with the expectation that there may be future changes as Paul indicated? (And, of course, the possibility of reverting one or both new features before the release if we discover major problems)

pzinn · 2025-12-25T04:29:51Z

fine with me

mikestillman · 2026-01-02T15:15:53Z

I am looking at the final PR, and will review it too, and I will have comments (already do, but going back over the long discussion to make sure I don't re-ask too many questions. I think I like this version now, but I want to make sure it doesn't slow things down, and that the doc matches the actual behavior (e.g. doc mentions try code except code else code but this isn't allowed?)

Also swap its values, i.e.: * true = yes, we caught an error * false = no, we didn't, either because it wasn't an error or it was some error we couldn't catch (syntax, interrupting)

Raise them instead

d-torrance · 2026-01-02T19:13:39Z

Oops -- try x except y else z was definitely a typo! I've fixed it, and also documented the try/then/except/do case that Mahrud added.

mikestillman · 2026-01-02T21:38:48Z

@d-torrance Thanks! Perhaps we should also add to the "error handling" node "stopIfError" (a mutable variable), and a sentence about trap?

It seems like other things that I thought were a problem have somehow been fixed since I tried this yesterday? Not sure... (I needed to do new SelfInitializingType of Error rather than new Type of Error. Both seem to work now...)

d-torrance · 2026-01-02T21:57:36Z

Sounds good! I've updated "error handling" as requested.

The only difference between SelfInializingType and Type, I think, is that the former lets you do MyError "foo" but the latter needs new MyError from "foo".

Mention "trap" in the description, and also add a link to stopIfError.

mikestillman · 2026-01-05T16:28:20Z

It seems like we have 5 different forms for try blocks. Perhaps we should deprecate a couple versions, or give guidance about which should be used? Which ones are currently used? (That question is for myself, I'll take a look!)

I do like the trap function/keyword though!

mikestillman · 2026-01-05T16:42:20Z

I found the problem: The extended markdown package (well, one of 3 different packages I just disabled) was grabbing shift-enter... Disabling them, and restarting makes it work.

d-torrance · 2026-01-05T16:44:02Z

There are six forms:

try x
try x else z
try x then y
try x then y else z
try x except err do z
try x then y except err do z

They're all documented in this PR. I don't see a problem with having this many -- it doesn't hold a candle to all the different forms of for statements, for example!

mahrud · 2026-01-06T04:17:20Z

I agree with Doug about different forms of try.

The extended markdown package

There's a markdown package?!

mahrud · 2026-01-12T20:09:02Z

@mikestillman is this good to merge?

d-torrance mentioned this pull request Dec 4, 2025

Add caughtError variable #4047

Closed

mahrud reviewed Dec 4, 2025

View reviewed changes

M2/Macaulay2/packages/Cremona.m2 Outdated Show resolved Hide resolved

d-torrance force-pushed the attempt branch from d3a9eb3 to 9ceceb4 Compare December 4, 2025 17:21

d-torrance requested review from antonleykin and pzinn December 4, 2025 17:21

antonleykin requested changes Dec 8, 2025

View reviewed changes

d-torrance force-pushed the attempt branch 2 times, most recently from 8be50f4 to 85964c6 Compare December 8, 2025 13:07

d-torrance force-pushed the attempt branch from 85964c6 to 67a493c Compare December 8, 2025 13:10

d-torrance force-pushed the attempt branch from 67a493c to ce77388 Compare December 10, 2025 02:30

d-torrance added 6 commits December 23, 2025 12:04

Document and add tests for "trap" and "Error"

9989b8d

Update JSONRPC to use "trap" for better error messages

ff69d50

Also bump to version 0.2 and start a changelog

Add "try ... except... do" statement for catching errors

bc275cf

Refactor RobustPrintMethod

8c21ed9

Now takes a single input (the object to print) and leaves the formatting of the message to the caller. Also renamed to RobustPrintNetMethod so we can also have RobustPrintSringMethod (which we'll use for arbitrary errors)

Move toString(FilePosition) to interpreter

c894859

Move "error" completely to the interpreter

a04cb53

d-torrance force-pushed the attempt branch from eb3d323 to 35810ce Compare December 23, 2025 17:06

d-torrance and others added 7 commits January 2, 2026 14:11

Rename tryEvalSuccess -> tryCaughtError for clarity

10851d7

Also swap its values, i.e.: * true = yes, we caught an error * false = no, we didn't, either because it wasn't an error or it was some error we couldn't catch (syntax, interrupting)

Don't trap errors that aren't caught by "trap"

1fed1bf

Raise them instead

Update "disassemble" tests for new try behavior

d023881

moved trapfun close to tryEval

ee78402

separated evalTryCode in evaluate.d

69eeb9a

added 'try .. then .. except .. do ..' clause

4d1d375

Document and add test for try/except/do

feabff1

d-torrance force-pushed the attempt branch from 35810ce to feabff1 Compare January 2, 2026 19:12

Add a couple things to "error handling" documentation node

a4df861

Mention "trap" in the description, and also add a link to stopIfError.

d-torrance force-pushed the attempt branch from 346f6f7 to a4df861 Compare January 2, 2026 22:03

Add "trap" keyword for Go-like error handling #4051

Are you sure you want to change the base?

Add "trap" keyword for Go-like error handling #4051

Conversation

d-torrance commented Dec 4, 2025

Uh oh!

Uh oh!

mahrud commented Dec 4, 2025

Uh oh!

seangrate commented Dec 4, 2025

Uh oh!

d-torrance commented Dec 4, 2025

Uh oh!

pzinn commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pzinn commented Dec 5, 2025

Uh oh!

pzinn commented Dec 5, 2025

Uh oh!

d-torrance commented Dec 5, 2025

Uh oh!

d-torrance commented Dec 5, 2025

Uh oh!

mahrud commented Dec 5, 2025

Uh oh!

pzinn commented Dec 7, 2025

Uh oh!

antonleykin left a comment

Choose a reason for hiding this comment

Uh oh!

antonleykin Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

d-torrance Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

antonleykin Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

d-torrance Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

d-torrance commented Dec 8, 2025

Uh oh!

mahrud commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pzinn commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mahrud commented Dec 9, 2025

Uh oh!

d-torrance commented Dec 9, 2025

Uh oh!

pzinn commented Dec 9, 2025

Uh oh!

d-torrance commented Dec 10, 2025

Uh oh!

mahrud commented Dec 10, 2025

Uh oh!

pzinn commented Dec 10, 2025

Uh oh!

mahrud commented Dec 10, 2025

Uh oh!

mahrud commented Dec 23, 2025

Uh oh!

d-torrance commented Dec 23, 2025

Uh oh!

mahrud commented Dec 24, 2025

Uh oh!

pzinn commented Dec 25, 2025

Uh oh!

mikestillman commented Jan 2, 2026

Uh oh!

d-torrance commented Jan 2, 2026

Uh oh!

mikestillman commented Jan 2, 2026

Uh oh!

d-torrance commented Jan 2, 2026

pzinn commented Dec 5, 2025 •

edited

Loading

mahrud commented Dec 9, 2025 •

edited

Loading

pzinn commented Dec 9, 2025 •

edited

Loading