Idea for a language addition for error handling: inject/eject

[Gorka Guardiola]

I have the following idea [1] for decluttering error handling in go. It looks similar to others already presented, but is is different in important ways:

1) It does not interfere with or use panic

2) Is general enough that one can wrap errors with other errors or check different kinds of errors.

3) Hopefully it does not disturb the flow of code to make it difficult to read (it is similar to return,

not to exceptions, it is not thrown and caught).

Maybe something like this has been proposed before, but I am not aware of it.

This is an informal writeup, hopefully it is understandable enough, but if not, feel free to ask any questions.

Thoughts?

[1] https://docs.google.com/document/d/1VUDGX_y8MPnNLBActbefFjZlp6EaaGcoflZy6OS8p9c/edit?usp=sharing

--

- curiosity sKilled the cat

[Ian Lance Taylor]

On Wed, Nov 9, 2022 at 10:40 AM Gorka Guardiola <pau...@gmail.com> wrote:
>
> I have the following idea [1] for decluttering error handling in go. It looks similar to others already presented, but is is different in important ways:
>
> 1) It does not interfere with or use panic
> 2) Is general enough that one can wrap errors with other errors or check different kinds of errors.
> 3) Hopefully it does not disturb the flow of code to make it difficult to read (it is similar to return,
> not to exceptions, it is not thrown and caught).
>
> Maybe something like this has been proposed before, but I am not aware of it.
>
> This is an informal writeup, hopefully it is understandable enough, but if not, feel free to ask any questions.
>
> Thoughts?

Seems related to https://go.dev/issue/54361, although due to inject it
is not the same.

Ian

[Gorka Guardiola]

I hadn't seen that proposal.

It is similar in the sense that it is a more powerful return, but this is much more limited and restricted (1 call level explicitly annotated in the function call vs. returning N levels to a label/function name). In that sense it is a subset of what can be done with that change but more structured. I feel it could be easier to reason about.

The changes to the language, runtime, compiler... are also quite more limited. The bad part is the need for two new reserved words.

G.

[Mike Schinkel]

Hi G.,

It takes guts to make a proposal in the Go community. Kudos for doing so.

However,  the issue with this proposal for me is the issue I have with almost(?) every other proposal to handle errors in Go differently from what Go currently allows. They all make the assumption that as soon as an error occurs the only thing I would want to do is an immediate return, which I almost never do.

Instead I almost always annotate errors with context to help when debugging logs, and often do some analysis to potentially resolve the error — such as a retry, or ignoring when not relevant — and the current structure of Go error handling, while I am sure it could be improved somehow, currently works extremely well for this.

Also, I don't really like the idea of having to create a different function located a distance away in terms of code location from where the error occurs in order to be able to handle an error.  I much better how Go optimizes my ability to address an error exactly at the point in which I recognize that an error occurred.

As an aside, I would rather see Go make it easier to annotate errors with context in a way that does not require so much duplication of effort throughout the code than make it easier to just return early.

So from a concerned-for-my-own-interests perspective if something that makes it easier to do an immediate return on `err!=nil` were added to Go and it were to be used ubiquitously it would make it much harder to me to stick with Go moving forward. #fwiw

-Mike

[Gorka Guardiola]

On Sat, Nov 12, 2022 at 12:40 AM Mike Schinkel <mi...@newclarity.net> wrote:

Hi G.,

It takes guts to make a proposal in the Go community. Kudos for doing so.

Or recklessness :-). Thanks.

 

However,  the issue with this proposal for me is the issue I have with almost(?) every other proposal to handle errors in Go differently from what Go currently allows. They all make the assumption that as soon as an error occurs the only thing I would want to do is an immediate return, which I almost never do. 

Instead I almost always annotate errors with context to help when debugging logs, and often do some analysis to potentially resolve the error — such as a retry, or ignoring when not relevant — and the current structure of Go error handling, while I am sure it could be improved somehow, currently works extremely well for this.

The idea behind this proposal is to make it easy to factorize this kind of process (adding the context to the error, and so on) in a function. It is generally repetitive and could be done in a function once an reused. Following the inject proposal, you could inject a function call with the Context and logs as parameters and deal with that in there. If you are not returning from the original function you can just return and proceed normally. If you need some context, you could just pass it that. For example:

inject BailAnotatingError(ctx, err) 

 

Also, I don't really like the idea of having to create a different function located a distance away in terms of code location from where the error occurs in order to be able to handle an error.  I much better how Go optimizes my ability to address an error exactly at the point in which I recognize that an error occurred.

Well, this is always the case when writing a function, procedure or method. You move the flow of code somewhere else, and there is a balance between sharing the state

(and having too much state and clutter) and hiding it (by moving it somewhere else) but naming it descriptively. 

As an aside, I would rather see Go make it easier to annotate errors with context in a way that does not require so much duplication of effort throughout the code than make it easier to just return early.

This is *exactly* what the proposal is trying to do. Injected functions can do all this. Maybe I am not understanding you? See in the proposal the ErrBailMsg, for example

(I have changed it a little to make it clearer and fix some names).

 

So from a concerned-for-my-own-interests perspective if something that makes it easier to do an immediate return on `err!=nil` were added to Go and it were to be used ubiquitously it would make it much harder to me to stick with Go moving forward. #fwiw