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(a)
y, _ := strconv.Atoi(b)
z, err := strconv.Atoi(c)
if err != nil {
return err
}
fmt.Println("result:", x + y + z)
return nil
}
How is sound?
Semih.
On Sunday, 2 August 2020 at 11:44:43 UTC+3 Denis Cheremisov wrote:
> 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 := doSomething(); err != nil {*
> *}*
>
> and
>
> *v, err := returnSomething()*
> *if err != nil {*
> *}*
>
> *or err* would do this better for sure
>
> *doSomething() or err {*
> *}*
>
> and
>
> *v := returnSomething() or err {*
> *}*
>
> воскресенье, 2 августа 2020 г. в 03:55:59 UTC+3, [email protected]:
>
>> 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("ConIo")){}
>>
>> Actually I suppose it is an issue, I do not do error handling in Go, but
>> my preprocessor converts it to Go. Go error handling can do anything, the
>> implementation may not be clear and that may be the real problem. We can
>> change it by improving the language or by training programmers on
>> recognizing useful abstractions, may need both.
>>
>>
>> On Saturday, August 1, 2020 at 1:31:54 PM UTC-5 Ian Lance Taylor wrote:
>>
>>> On Sat, Aug 1, 2020 at 10:59 AM <[email protected]> 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 maintaining the status quo... despite, IMHO, several good
>>> alternatives that have been suggested on this very forum.
>>>
>>> There have been many alternatives suggested, but none of them have
>>> been clearly better.
>>>
>>> I recently wrote a brief overview at https://golang.org/issue/40432.
>>>
>>> Ian
>>>
>>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/d4db0d43-3935-4d3e-8f93-ab4852fda8d1n%40googlegroups.com.
