Less cluttered error handling in cells.

[Michael-F-Ellis]

I put a notebook in CoLab that demonstrates a possibly useful way to reduce the visual clutter from the usual way of handling errors in Go. I think it's especially applicable to notebooks, where some may perceive that Go's verbosity suffers in comparison to Python.

Please take a look and let me know if it seems worth incorporating into some % magic for gonb.

If so, I'd be happy to look into implementing the magic and submitting a pull request.

[Michael-F-Ellis]

Oops, forgot to share the notebook. Should be public now.
https://colab.research.google.com/drive/1Hy7MUE9KIb9qTLau_c6BF2bVpqWWMtUW?usp=sharing

[janpfeifer]

I have to say I like using exceptions (in Go translated to panic + recover) for simple cases like this.

Would something like this be ergonomic to you:

import (
    "fmt"
    "github.com/janpfeifer/must"
)

func f(fileName string) (int, error) {
    return 0, fmt.Errorf("File %q is no good here", fileName)
}

%%
value := must.M1(f("hello_world.txt"))
fmt.Printf("value=%d\n", value)

Which outputs:

panic: File "hello_world.txt" is no good here

goroutine 1 [running]:
github.com/janpfeifer/must.init.func1({0x4ca068?, 0xc000104040?})
	/home/janpf/src/go/pkg/mod/github.com/janpfeifer/must@v0.0.2/must.go:10 +0x2e
github.com/janpfeifer/must.M1[...](...)
	/home/janpf/src/go/pkg/mod/github.com/janpfeifer/must@v0.0.2/must.go:38
main.main()
	 [[ Cell [3] Line 11 ]] /tmp/gonb_b7d00c6b/main.go:16 +0xb2
exit status 2

And, a slightly different version, using the gomlx/exceptions library, that works similar to your suggestion:

import . "github.com/gomlx/exceptions"

%%
err := TryCatch[error](func() {
    value := must.M1(f("hello_world.txt"))
    fmt.Printf("value=%d\n", value)
    //...
})
if err != nil {
    fmt.Printf("Error: %v", err)
}

Notice there is only one final if err != nil {} ... one could even write a small TryCatchPrint function that simply prints out the error.

Fundamentally it's doing the same thing:

1. Convert error to exception (panic), which I'm using the must library, where you define the ReturnIfError. I understand the semantics difference, but ... that's what's happening.
2. Capture the exception (recover) and printing out as an error with the var err error; defer Recover(&err) part. Notice here your version would discard a panic caused by other reasons, and the error would be lost.

Should gonb offer something special here ... I'm hesitant, because I'd rather to making it do too many things, except if it really can't be done with the language -- I've broken this rule at times though :(

Any thoughts ?

[Michael-F-Ellis]

Good thoughts. I wrote my suggestion before I spotted your Must functions in the FAQ.

On further consideration, I think the most universal approach would be to create a line magic that injects a user-defined string into the code just before compile time. For the sake of discussion, let's call it %inject.

So one might define in a cell at the top of the notebook, something like:

// rif can be injected as a boilerplate error return
const rif = `
if err != nil {
   fmt.Printf("Error: %v", err)
   return
}`

// or if you prefer a panic
const pif = `
if err != nil {
  panic(err)
}`

and in a later cell

%%

result, err := SomeFunc(...)
%inject rif
// No error if we get to here

What I like about this approach is

1. The user gets to decide exactly how they want to handle errors.
2. It seems simple to reason about and hopefully easy to implement.
3. It's usable wherever someone needs a condensed way to insert arbitrary boilerplate code.

My only caveat is it opens the door for requests to let %inject take multiple args, fill in templates, execute functions that generate the code and so on. But I think that's something you could say no to on principle.

I'd be willing to prototype it if you can give some guidance on where to look in the repo.

[janpfeifer]

So ... this is a bit philosophical. But let me start with a couple of technical comments:

• gonb doesn't know about Go variables or constant values. So in your example I would expect something like a special command to set the value to be replaced: %set rif='if err != nil {...}'.
• %inject you propose is like a macro. One could as well add parameters to it.
• error handling inside the injected macro would be messy and hard to translate to line number ...

Now the philosophical (choice) aspects (it will sound opinionated, but let me say in advance I'm not religious about these things, and really open to changing my mind if there are good arguments):

• One of the hallmarks of Go is to have fewer ways to do things, to make it simpler to read. Macros is a "side meta-language" (and foot-shooter), and is one of those things that Go clearly steered away -- actually, one of the things I hate in Rust (but I haven't used it enough), I can't believe they added macros to the language :( ... it's such giant source of issues and major headaches in C/C++.
• A counter argument to above is go:generate which is kind of like macro, it runs before the compiler ... but anyway, it doesn't feel part of the language, but rather an add-on that someone can add at their own risk. Example the Templ sub-language (which btw after trying I really don't like, it's has some really odd/arbitrary constructs that sometimes work, and in other contexts doesn't, it feels like a bad PHP).
• Another aspect to consider is that the common use case on gonb is different maybe than the common use case in Go ... so one could argue that what is good for Go may not be ideal in gonb. But at the same time, folks wouldn't want to have to learn to read another language ... Meaning if someone shares the colab, how would one read %inject rif. Actually, the same can be said about %% special command, I hesitated a lot before creating it. But it was such a common use case, and the aspect that each cell has its own func main so to say, which I thought it was a new concept that could have the excuse to have something new -- at least that's what I told myself 😄

Ok, with that in mind ... I'm hesitant to include %inject as a default command. But I wonder if there was a way to create add-ons to gonb and allow one to extend it relatively easy. Just like Go allows one to create dialects wtih go:generate.

Any thoughts ?

[Michael-F-Ellis]

Hey, thanks for taking the time to share your thoughts. You're absolutely right about %inject not being able to access the value of a go const or var before compile time. So yeah, it would have to be a some kind of macro.

I'm pretty much in agreement with your concerns. To tell the truth I almost never use my Return/Recover mechanism in ordinary Go code unless I'm writing a series of function calls that all must succeed. In the remaining 99% of cases, I simply use the tried and true if err != nil { ....

Funny enough, I tried using an automatic folding extension to collapse them, but found that I couldn't resist clicking the little expansion triangles to see what I already knew was inside :-) . Then I found a little extension that detects if err != nil and dim the colors of the whole expression.

I've been happy with that solution for a couple of years now, especially now that Copilot usually suggests what I would have typed anyway. So I guess the question is whether gonb notebooks are different enough from regular coding to justify a different approach. I see three cases:

Notebook as scratchpad.

As I said in another discussion, gonb fills the void left by abandoning iPython. I'm now keeping an untracked notebook named gonb.ipynb in my projects to use for testing ideas. If a chunk of code works well, I want to paste it into a project file with as little modification as possible. Explicit if err != nil handling is a win in that scenario.

Notebook as data analysis

Stronger case for shortcuts/macros here since the emphasis is on the cell outputs, i.e., plots and tables.

Notebook as instruction

I suppose it depends on what the notebook in intended to teach. If it's teaching Go programming, then the less magic the better. OTOH, if it's showing how to run an image diffusion pipeline, then hiding boilerplate error handling might well be a good thing.

A big consideration for you is what kind of long-term maintenance headaches come with each added feature versus the value it adds for users. (FWIW, I think the %% to wrap the following cell content in a main() is brilliant. It's a great example of code generation that adds value and is easy to reason about.)

[Michael-F-Ellis]

@janpfeifer We had snowstorm today here in northwestern Vermont, so I had some time to spend trying out various error handling methods and syntaxes. I don't think any new magics would add real value just for error handling. I'll be using either the tried and true if err != nil ... or occasionally a simple check and panic like

func Check(err error, msg string) {
	if err != nil {
		panic(fmt.Errorf("%s: %v", msg, err))
	}
}

You wrote:

I wonder if there was a way to create add-ons to gonb and allow one to extend it relatively easy. Just like Go allows one to create dialects with go:generate.

Well, one simple and very general approach is to use your shell command mechanism to call a user program that generates code. That's essentially all go:generate does.

With go:generate the program outputs typically go to a .go file, but with a notebook it would be nice to have the generated code go into a cell. Maybe you could use !! to mean, execute a shell command and put its stdout into the current cell, e.g.

var generated string = `
// !! mycodegenerator options args ...
// Generated output goes here.
`

In the above, I wrapped it all in backquotes to prevent the generated code from being executed immediately. Seems to me one would usually want to look at the result before trying to run it. Or maybe the generator output should go into a new cell just after the current one.

Obvious, one could do most of this already in gonb with any generator that writes to stdout, but it would be a convenience not to have to cut and paste from the cell output.