> In many cases, including in the standard libraries, there are functions
that return errors and then accompanying functions with names like
MustFoo() that just call Foo() and panic if there's an error.
At least inside the standard lib, the uses of MustXxx document why they
behave the way they do. I think the language could be written something
like "this package considers any error in constructing a template to be a
severe error that necessitates panic", or "... to be a runtime exception"
without changing the reasoning about why that behavior has been chosen.
On Monday, October 24, 2022 at 5:38:22 AM UTC-7 ren...@ix.netcom.com wrote:
> Dan,
>
> If it walks like a duck…
>
> You make a great case why Go should have checked exceptions. If anything
> the Go error handling model tries to be checked exceptions - every error
> should be explicitly handled - without any of the conveniences of
> exceptions - common blocks, stack traces and call stack unwinding.
>
> On Oct 24, 2022, at 4:52 AM, Harri L <har...@gmail.com> wrote:
>
> 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...@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
>
> <https://groups.google.com/d/msgid/golang-nuts/1d1e051d-4485-4fe0-a9c8-16afdc5d80e6n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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/9bd8c9f2-de2c-416f-bef1-f909aeaa5b84n%40googlegroups.com.
