I actually prefer the explicit error handling:
```
f, err := os.Open("path")
if err != nil {
//handle error
}
```
When you are reading the code to look whether a certain condition has been
handled, the explicit branching statement makes it easier to scan.
On Wednesday, February 17, 2021 at 1:46:07 AM UTC+7 [email protected]
wrote:
> I wanted to express my thanks to Mickael McKinnus for his research.
>
> I am someone who is quite happy with the error handling in Go as it lets
> me implement whatever I like, I must say it is obviously flawed from the
> standpoint that the proper constructs are not part of the language but part
> of our training. The discreet patterns I use are:
>
> - Handle errors that can be handled close to where they occur.
> - Report errors that cannot be handled because they were caused by the
> calling function passing a bad parameter.
> - Panic on errors that prevent a function that MustComplete from
> completing because they cannot be handled.
> - Try a MustComplete() with recover from the panic that reports to the
> User and or Developer the nature of the problem and how to resolve it
> manually or at least add it to issues.
> - Ensure that no matter what happens, you do not corrupt the HDD,
> lockup the hardware, CTD, or leave unexpected artefacts on the screen.
>
> There is no one best way of dealing with errors but there are patterns for
> dealing with errors, if you only learn one pattern then you will not be
> writing good code (if you only have a hammer, everything looks like a nail).
>
> Golang does not have error patterns that are clear and distinct for novice
> programmers and it does not inhibit advanced programmers from dealing with
> errors in whatever way they think appropriate.
>
> A useful abstraction would be to simplify the error handling by
> identification of the type of pattern desired and use the most concise and
> yet easily understood way of writing it. Go has tools in place to allow
> each user to create a preprocessor for error handling or any other purpose
> but it would be nice if we were all on the same page.
>
> On Monday, February 15, 2021 at 12:53:43 PM UTC-6 [email protected]
> wrote:
>
>> And I will tell you that after working with error returns and exceptions,
>> exceptions are superior - but much depends on the complexity of the system.
>> For small system level tools that are pieced together via pipes, C error
>> handling is fine - because the process serves as the exception handling
>> point. For complex server long-lived processes, exception handling makes it
>> much easier to design and deliver secure fault tolerant systems. Resilient
>> Unix relies on the ability to start new processes to handle requests, track
>> DoS attacks, faulty clients, etc. Process termination is a part of this.
>> The Go runtime does not fit this model, so it needs to replicate it.
>>
>> People write bad exception code - people write bad error return code.
>> It’s easier to write and maintain good exception code. To this day, very
>> few major systems are written in Go - at some point we have to ask honestly
>> why - I think Go’s error handling is an important factor here.
>>
>> Go can probably get there without exceptions, but it entails standardized
>> error declarations, wrapping, inspection, logging, etc. I think the Go2
>> error handling proposals attempt this.
>>
>> On Feb 15, 2021, at 11:25 AM, Volker Dobler <[email protected]>
>> wrote:
>>
>> I think there is strong consensus, that the current style of error
>> handling is currently the best option. Nobody has been able to come up with
>> something better (really better, not just more comfortable while ignoring
>> hefty drawbacks).
>>
>> It is true that a loud minority seems to miss exceptions to a point where
>> they are unwilling to even try the language. How much their expertise
>> counts if they never really worked with proper error handling in Go is
>> debatable. Having worked with error returns and exceptions I can tell you
>> that proper error handling with exceptions is much more painful than with
>> errors. But of course: If your infrastructure, your business requirements
>> and your acceptance criteria allow for making any problem a problem of
>> someone else than exceptions are godsend.
>>
>> V.
>>
>> On Sunday, 14 February 2021 at 17:41:18 UTC+1 [email protected] wrote:
>>
>>> I think ’strong census’ is not accurate - thus the discussions around
>>> improving error handling in Go2.
>>>
>>> Many have commented here and elsewhere that the number one reason they
>>> don’t use Go is due to lack of exception handling.
>>>
>>> > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki <[email protected]>
>>> wrote:
>>> >
>>> > Dnia 2021-02-13, o godz. 17:44:47
>>> > Michael MacInnis <[email protected]> napisał(a):
>>> >
>>> >> I've been playing around with reducing error handling boilerplate
>>> >
>>> > You're not alone. Hundreds of us went into such thinking in the first
>>> weeks
>>> > of reading/using Go - yet before we noticed how much more productive
>>> we
>>> > are with Go's "boilerplate" than we were in languages where handling
>>> errors
>>> > (failures) was "a problem of others", including future-us as "others".
>>> >
>>> > Perceived consensus of the Go community is that "error handling
>>> boilerplate"
>>> > is a strong feature. I.e. in normal production software you MUST
>>> handle failures
>>> > and you should do it as close as possible to the source of said
>>> failure.
>>> >
>>> > Go helps with that. Even team's proposal was finally retracted:
>>> > https://github.com/golang/go/issues/32437 Discussion there is
>>> lengthy, but worth
>>> > reading to sense why wider community considers "boilerplate" as asset.
>>> >
>>> > Error handling proposals umbrella:
>>> https://github.com/golang/go/issues/40432
>>> >
>>> >> Michael.
>>> >
>>> > Hope this helps,
>>> >
>>> > --
>>> > Wojciech S. Czarnecki
>>> > << ^oo^ >> OHIR-RIPE
>>> >
>>> > --
>>> > 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/20210214171250.4377c454%40xmint.
>>>
>>>
>>>
>>>
>> --
>> 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/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/d9cdb32d-2609-4ae9-a9ff-36830c877245n%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/32657f71-d9c1-4a79-9528-ad6a73af954cn%40googlegroups.com.
