Hi,
On Friday, October 21, 2022 at 12:14:52 AM UTC+3 dple...@google.com wrote:
>
> var x0 float
> try {
> x0 = check DoSomeMath(check FetchSomething(), check ComputeSomething())
> } handle err {
> log.Info("Unable to estimate initial approximation, defaulting to 1...")
> x0 = 1
> }
> // code continues and does things with x
>
I wanted to show what the previous block looks like with the help of the
current Go and some help from the err2 <https://github.com/lainio/err2>-package
(I'm the author). The Go playground <https://go.dev/play/p/Yjaj4yy7frR>.
calcSomething := func() (x0 int) {
defer err2.Catch(func(err error) {
log.Printf("Unable to estimate initial approximation: %v,
defaulting to 1...", err)
x0 = 1
})
return try.To1(DoSomeMath(try.To1(FetchSomething()),
try.To1(ComputeSomething())))
}
x0 := calcSomething()
Of course, that's not exactly what you are proposing:
This makes it easy to see what error handling will happen at any point
> within the function, keeps the control flow linear (so that, unlike
> defer()-based recovery, you don't have to skip ahead in the function to get
> context before the handler makes sense - the context comes first, followed
> by the handling code), and allows code to recover from errors without
> aborting an entire function.
>
I also wanted to say that the `defer` -based error handling isn't so bad
when you are used to the defer keyword already in the Go.
Best Regards,
-Harri
--
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/1d1e051d-4485-4fe0-a9c8-16afdc5d80e6n%40googlegroups.com.
