Re: [go-nuts] Re: Why we don't have simple throws error statement

Even worse: no idea where the error actually happened. вторник, 18 августа 2020 г. в 13:33:54 UTC+3, semi...@gmail.com: > Another idea, if we use blank identifier for errors then throws statement > catch these with caller function name. > > func printSum(a, b, c string) error { > throws f

Re: [go-nuts] Re: Why we don't have simple throws error statement

Another idea, if we use blank identifier for errors then throws statement catch these with caller function name. func printSum(a, b, c string) error { throws func(caller string, err error) { fmt.Println("caller:", caller, err) return err }() x, _ := strconv.Atoi

[go-nuts] Re: Why we don't have simple throws error statement

I disagree with error handling proposals that hide the program flow's branching statements. In 1976, Thomas McCabe found a correlation between branching statements and bugs. His cyclomatic complexity uses program flow to measure code complexity. It is important that branching statements be pla

Re: [go-nuts] Re: Why we don't have simple throws error statement

There are two major issues with Go error handling: 1. It is not strict enough, i.e. the compiler cannot ensure error check 2. It is not consistent enough. In the first you can easily ignore an error and the compiler will let you go further. In the second, you can both *if err := doSometh

Re: [go-nuts] Re: Why we don't have simple throws error statement

I do not consider error handling an issue but then again I tend to either use the Doit() err{} or MustDoit(){} panic and then use DI (dependency injection implemented by interface) for error-handling so that I can get an email when we get a new error. So then it would be MustDoit(errorHandler(

Re: [go-nuts] Re: Why we don't have simple throws error statement

On Sat, Aug 1, 2020 at 10:59 AM wrote: > > Has anyone ever tallied the number of different forum threads related to > changing Go error handling ? > The current method is obviously a vexing issue to many Go users, and > It seems silly that this issue has never been resolved by the Go team beyond

[go-nuts] Re: Why we don't have simple throws error statement

Has anyone ever tallied the number of different forum threads related to changing Go error handling ? The current method is obviously a vexing issue to many Go users, and It seems silly that this issue has never been resolved by the Go team beyond maintaining the status quo... despite, IMHO, se

[go-nuts] Re: Why we don't have simple throws error statement

Your "throws" statement (why is it called "throws" when it "catches" according to the comment?) looks a lot like the "handle" block from the first draft design by the Go team: the check/handle proposal . On Friday

[go-nuts] Re: Why we don't have simple throws error statement

I think that's because no-one has been able to come up with a detailed, specific proposal where the end result is both simple and clear, when compared to the current situation. My idea, if it's worth anything, is to have Python-style post conditionals: return "", err if err != nil I expect it

[go-nuts] Re: Why we don't have simple throws error statement

I did not see clear and simple either. As I wrote, I don't like complex solutions. Just trying to ask: why we don't have simple solution. The function just simple example, this isn't a draft or something. On Friday, 31 July 2020 at 23:25:26 UTC+3 b.ca...@pobox.com wrote: > On Friday, 31 July 2

[go-nuts] Re: Why we don't have simple throws error statement

On Friday, 31 July 2020 15:06:33 UTC+1, semi...@gmail.com wrote: > > I know, there are so many discussion about error handling. I read tons of > idea about that. Looks like most of idea rejected from community but every > idea brings our goal closer. > The more I use go's existing error handling

[go-nuts] Re: Why we don't have simple throws error statement

Note; I don't want to send any proposal currently. Firstly, I would like to share and discuss my idea with community. On Friday, 31 July 2020 at 17:06:33 UTC+3 Yasar Semih Alev wrote: > Hey Community, > > I know, there are so many discussion about error handling. I read tons of > idea about tha