Go can already pass/pipe the result of a function, which returns multiple
values, to another function, which accepts the same values as arguments.
Now, assume we have a function named funcCtx:
func funcCtx() (res int, err error) {
// ...
}
Having that, these does not look that ugly:
func funcCtx() (res int, err error) {
res, return() = action()
// or
res, panic() = action()
}
Those statements will have an effect, only if the returned value is not
nil. For performing some actions, before the actual return or panic:
res, return({ log.Println(err) }) = action()
There is this restriction, that the function that contains this block,
funcCtx, has to return named return values - for both handling the zero
values and having a one to one mapping between its return values and those
of action function.
Also for having a name, err in this case, that makes it clear, which
variable we are talking about.
In the proposal
<https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md>,
it's not clear where the err variable comes from (what if there are three
return values?)
On Monday, July 8, 2019 at 4:17:58 PM UTC+2 ren...@ix.netcom.com wrote:
>
> I think the xerrors proposal will solve a lot of people's problems. You
> still repetitive boilerplate, but at least decent debugging is possible.
>
> -----Original Message-----
> From: Chris Broadfoot
> Sent: Jul 8, 2019 9:04 AM
> To: Robert Engels
> Cc: Chris Passas , golang-nuts
> Subject: Re: [go-nuts] Go 2018 Survey "Error handling 5%"
>
> See the errors proposal here:
> https://golang.org/design/29934-error-values
>
> Implementation in tip (available in 1.13 beta)
> https://tip.golang.org/pkg/errors/
>
> Implementation in x/xerrors (backwards compatible):
> https://godoc.org/golang.org/x/xerrors
> xerrors - GoDoc
>
>
> On Mon, Jul 8, 2019, 9:54 AM Robert Engels <ren...@ix.netcom.com> wrote:
>
>>
>> I think you are on to something. As I've said, the boilerplate is ugly,
>> but manageable. It is the process of using and reporting errors that is the
>> problem.
>>
>> If the error interface were expanded, to included methods like
>>
>> int Type()
>> int SubType()
>> []Stack StackTrace()
>> error Cause()
>> Log(w Writer,string format,...)
>>
>> with stdlib defining constants for errors, and user developed constants >
>> N, the chances of constant collision is minimal.
>>
>> Alternatively, define like this
>>
>> string Type()
>> string SubType()
>>
>> with the Type being package.SomeErrorName
>> and sub-type being package.SomeErrorName.SubErrorName
>>
>> to allow easier capture and retry.
>>
>> To go even further, add a
>>
>> bool Permanent()
>>
>> to signify if the same call is made with the same parameters, it is also
>> fail - unless some action is taken (network reconfig, etc.) This is a more
>> difficult implementation, but could be just a 'hint'.
>>
>> It's is some amount of work to define the constants, and change existing
>> code, but it is just busy work. The Go error handling is worse than C in
>> that at least in C, the api doc clearly spells out which error codes can be
>> returned, and why. With the Go error interface, and the 'minimal api doc',
>> what is returned when is anybody's guess.
>>
>>
>>
>> -----Original Message-----
>> From: Chris Passas
>> Sent: Jul 8, 2019 8:32 AM
>> To: golang-nuts
>> Subject: [go-nuts] Go 2018 Survey "Error handling 5%"
>>
>> We are all aware error handling was tied for 4th most common challenging
>> when working with Go in the 2018 survey.
>>
>> There is not description of what about error handling. I'm sure I missed
>> the conversation but how did we get to the point of deciding it was the if
>> err!=nil that was the "challenging part"?
>>
>> Personally the only thing I wish was different was we could have error
>> times/categories in addion. Basically just a way to allow us to not need
>> the following.
>>
>> if strings.Contains(err.Err(),"timeout")
>>
>> Most of the time all you care is there was an error and don't parse the
>> message to decide what to do next. There are cases where you might decide
>> how to handle it based on the message.
>>
>> There are messages like "Connection failed to -> 192.168.1.1", this is
>> useful but also makes the error something you can't check for without
>> substring parsing.
>>
>> What if we could do something like
>>
>> if err.Type()=="Bad Connection"
>>
>> but then you could still return or log the 'err' as normal and get that
>> extra info.
>>
>> --
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/fa12d854-c317-4477-98b1-32ca883d2093%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/fa12d854-c317-4477-98b1-32ca883d2093%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/1215816141.2411.1562594037454%40wamui-charming.atl.sa.earthlink.net
>>
>> <https://groups.google.com/d/msgid/golang-nuts/1215816141.2411.1562594037454%40wamui-charming.atl.sa.earthlink.net?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>
--
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/02b8d1d7-fb4f-4548-b029-ebb3ca49284an%40googlegroups.com.
