Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-09 Thread Shulhan
Hi Mike, On Thu, 29 Jun 2023 22:04:01 -0700 (PDT) Mike Schinkel wrote: > There are many aspects of this proposal that I really like, and a few > that I think need to be reconsidered. > > In general I like that it: > >1. Does not try to handle errors *above *where the errors > occurred, whi

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-03 Thread Mike Schinkel
Hi Henry, For clarity, my comments were not intended to call out any lack of motivation — which you keyed on — but instead focus on the fact no silver bullet is likely to exist that addresses error handling without new language features, and that many Go developers want error handling addresse

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-02 Thread Henry
I don't think it has anything to do with motivation, Mike. The problem I see is that there is no good enough solution that offers a substantial benefit over the current approach. Many error handling proposals involve rearranging the code with a few line savings, and sometimes at the cost of rea

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-02 Thread Mike Schinkel
On Wednesday, June 28, 2023 at 1:30:41 PM UTC-4 Sven Anderson wrote: I think for what you want to do you don't need any language extension. On Sunday, July 2, 2023 at 2:04:29 PM UTC-4 Harri L wrote: *The sample block below is what we can have without any language updates.* Many times when pe

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-02 Thread 'Dan Kortschak' via golang-nuts
On Sun, 2023-07-02 at 10:41 -0700, Jeremy French wrote: > Scrolling in code is bad - a necessary evil, obviously, but evil > nonetheless.  Vertical scrolling is bad because it causes what we > were looking at to move and our eyes have to track and/or reacquire > what we were looking at.  It's obvio

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-02 Thread Harri L
The sample block below is what we can have without any language updates. I will let you decide your thoughts about its readability, but please note that even the error strings are built automatically—error propagation with error traces, of course. Deferred error handling seems to clarify certai

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-02 Thread Jeremy French
Scrolling in code is bad - a necessary evil, obviously, but evil nonetheless. Vertical scrolling is bad because it causes what we were looking at to move and our eyes have to track and/or reacquire what we were looking at. It's obviously possible, but on the micro-scale it's expensive when yo

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-01 Thread 'Dan Kortschak' via golang-nuts
On Sat, 2023-07-01 at 22:34 -0700, Mike Schinkel wrote: > > What is the difference to if err != nil { goto } ? > > Thanks you for asking. > > If you run go fmt  on a file that contains the formatting you ask > about the line will be expanded to the 3 lines, which brings us back > to status quo:

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-01 Thread Mike Schinkel
Hi Sven, > *What is the difference to if err != nil { goto } ?* Thanks you for asking. If you run *go fmt* on a file that contains the formatting you ask about the line will be expanded to the 3 lines, which brings us back to status quo: *if * *err != nil { goto } *Of course *go fmt* coul

[go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-07-01 Thread Sven Anderson
Mike Schinkel schrieb am Fr. 30. Juni 2023 um 07:04: *when err!=nil goto * What is the difference to `if err != nil { goto }` ? Go is awesome, because it does _not_ more and more syntax, especially with subtle nuances that one has to remember. > -- You received this message because you ar

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-06-29 Thread Mike Schinkel
There are many aspects of this proposal that I really like, and a few that I think need to be reconsidered. In general I like that it: 1. Does not try to handle errors *above *where the errors occurred, which is the pattern when using both *defer* and *recover(). *I personally find ha

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-06-28 Thread Jan
Thanks for the pointer Sven! I think I was once told not to use panic/defer/recover to implement generic exceptions in Go, and never reconsidered it. I think I'm taking up on your suggestion for my library. On Wednesday, June 28, 2023 at 7:30:41 PM UTC+2 Sven Anderson wrote: > I think for wha

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-06-28 Thread Sven Anderson
I think for what you want to do you don't need any language extension. You can implement all that within the current language. Look at this example: https://go.dev/play/p/aqjwzknrArH If you want to catch errors also in nested functions, you can also skip the ErrorChecker type and do it like this:

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-06-16 Thread Shulhan
On Sun, 4 Jun 2023 12:36:20 -0700 Ian Lance Taylor wrote: > On Sun, Jun 4, 2023 at 9:17 AM Shulhan wrote: > > > > I have been reading several proposals about error handling couple of > > months ago and today a light bulb come upon me, and then I write as > > much as I can think. I am not sure i

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-06-04 Thread Ian Lance Taylor
On Sun, Jun 4, 2023 at 9:17 AM Shulhan wrote: > > I have been reading several proposals about error handling couple of > months ago and today a light bulb come upon me, and then I write as much > as I can think. I am not sure if its good or bad idea or even possible > to implement. > > In this po

[go-nuts] [RFC] Yet another proposal for Go2 error handling

2023-06-04 Thread Shulhan
Dear gophers, I have been reading several proposals about error handling couple of months ago and today a light bulb come upon me, and then I write as much as I can think. I am not sure if its good or bad idea or even possible to implement. In this post, I will try as concise as possible. The fu