On Sat, Nov 12, 2022 at 12:40 AM Mike Schinkel <m...@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 > -- - curiosity sKilled the cat -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CACm3i_hgPruq1gUBA9ESUqbBA9Td1U7T9P0g9Dm4dq3-dbYdbQ%40mail.gmail.com.
