Ben Hoyt's blog post Scripting with Go: a 400-line Git client that...
<https://benhoyt.com/writings/gogit/> mentions error handling from a
perspective that made me clear for the first time why I'm always in two
minds when it comes to Go's error handling:
1. the perspective of a prod-code package writer that will be used in
larger contexts: "[Go's error handling is] *simple and explicit [...]
It's not a big deal when writing production code, because then you want
more control over error handling anyway -- nicely-wrapped errors, or
human-readable messages [...]*"
2. from a "script" developer perspective, where "*all the error handling
you need is to show a message, print a stack trace, and exit the program*
".
There might be more angles to it, but Ben's sentiment rings a bell with my
own "customer" experience.
So we can at least expect to have two "camps of judges" when it comes to
error handling improvement proposals. Some of the judges might be acutely
aware of the at least two different angles, but some of the comments not
least in this thread ("language designers" as kind of gods who must ignore
their customers, seriously?) seem to indicate that this isn't always the
case. Not least, I also fall into the less desirable category of the
ignoramus.
So, maybe we should in the future always ask when it comes to a proposal:
which of the two perspectives does the proposal tackle? I'm under the
assumption that it might have been #2 in most of the proposals. The often
vivid negative responses should then be classified as belonging to #1
and/or #2. If the proposal is about #2, then #1 proponents don't
contribute, but simply make life hard for the #2 customers of the Go
language. Same for the opposite combination.
On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:
> Fair enough … I understand that people have different styles
>
> On Wednesday, August 2, 2023 at 12:54:20 AM UTC-6 Brian Candler wrote:
>
>> FWIW, I'm in the "I like how it is now better than any other proposal so
>> far" camp; I think this happens as you get used to the Go way. Go is Go.
>>
>> The only thing I would consider is making *interface* types (only)
>> implicitly usable in a boolean context, e.g.
>>
>> if err { ... }
>>
>> However, I suppose people would ask "why not pointers? why not channels?"
>> etc. I'm not suggesting it should become like Python where every non-zero
>> value is treated as "true". Interface values are special, and there's very
>> little you can do with a nil interface (whereas for example, a nil pointer
>> can still have methods called on it). But this does add a special case,
>> and Go already has its share of surprises you have to learn.
>>
>> On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:
>>
>>> Yes. Go is no longer the simple language it was. I suspect because of
>>> internal pressures within Google as evidenced by multiple innovations that
>>> seem to come from nowhere eg dir embedding and associated fs package that
>>> duplicated perfectly good ways of doing things. The module system while
>>> useful is quite complex. Generics and all the associated packages inflated
>>> the mental burden of learning and reading Go code significantly. And having
>>> the go 1 compatibility guarantee means that old stuff remains valid code
>>> and must be learned too.
>>>
>>> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:
>>>
>>>> Yeah.. I mean, the "idiom" `err != nil return` err is something of the
>>>> language. I complain about the boilerplate that idiom produces and that is
>>>> fact fact (no one can deny it).
>>>>
>>>> You know, your approach implies making the language a little more
>>>> complicated as new ways to deal with errors appear. I do understand that
>>>> some folks provide some push back on the idea simply because there is
>>>> nothing wrong with the language right now regarding error handling.
>>>>
>>>> As I see things, the language was simple in their origins, but from
>>>> time to time they complicated a little more some things, for example "what
>>>> about generics?" (are they really necessary?, I mean... I think using
>>>> interfaces provides all the genericity you may need). So I guess there is
>>>> room to make some changes and make the language easier. I would say that
>>>> both ways of handling errors are valid, the most important is to be as
>>>> simple as possible so you ensure that other people understand it. Like
>>>> Generics, you don't have to use them. So I would praise it for adding
>>>> another way, less repetitive.
>>>>
>>>> Also like to see how people react and what their opinions are. So far
>>>> what I read is just personal taste.
>>>>
>>>>
>>>> El mar, 1 ago 2023 a las 16:04, 'Luke Crook' via golang-nuts (<
>>>> golan...@googlegroups.com>) escribió:
>>>>
>>>>> And of course I forgot the "if" at the beginning of all those
>>>>> conditional. *sigh*
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "golang-nuts" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/golang-nuts/dRLR4hxxI8A/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> golang-nuts...@googlegroups.com.
>>>>>
>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> V
>>>>
>>>
--
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/924fc50f-d7c7-49ca-b340-9a1815cea1c2n%40googlegroups.com.
