Hacker News Reader

Comment by tsimionescu | Hacker News Reader

> The verbosity of

    if err != nil {
        return err
    }

> is outweighed by the value of deliberately handling each failure condition at the point at which they occur. Key to this is the cultural value of handling each and every error explicitly.

I've talked about this before, but it annoys me a lot that checking if an error exists and returning it is referred to as "handling the error". You are not handling anything - you're passing on responsibility up the stack just as clearly as if you had thrown an exception.

You're just doing it manually instead of letting the runtime do that for you. You're also making it much harder to tell the code that handles errors apart from the code which doesn't.

View on HN

I think what people usually mean in these situations is that you’re forced to think about the error.

Programs in C (and many other languages) have the problem that you can ignore errors accidentally.

Exceptions “solve” this by forcing some level of your stack to at least acknowledge that an error occurred. The problem with that model is that you still don’t have to think at any given level of the call stack what the appropriate handling is for any kind of error. You can just let it propagate up further, deferring responsibility.

For some code that might actually be appropriate, but often it results in code higher up that cannot possibly know how to deal with every error that can happen farther down the call stack just swallowing errors.

One thing I frequently see is mixing validation code with processing logic. By separating the two you can have the validation code deal with errors and the logic simply assert that it’s input is good (because it should have been validated by the error handling code before being passed in).

I think models where you are forced to think about errors at each level but have a simple mechanism to make them propagate up are probably the best single model if you have to choose one model for a language.

In any event, error handling is difficult and frequently doesn’t get the attention it deserves in the design and implementation of libraries and large systems.

In my experience, the vast majority of error handling has been essentially limited to bubbling the error up, cleaning up unmanaged resources, and either re-trying the operation with some back-out logic or giving some details to the user about what happened and letting them decide what the best thing is.

I have very rarely seen something useful to be done by code automatically to recover from an error, other then re-trying. As such, I feel that the way Go makes you constantly write error-handling code is counter-productive, since it forces you to think about something that really doesn't need that much thinking about.

And as I said earlier, the deluge of non-handling error handling code can serve to mask the rare cases where errors are actually handled in some tricky intelligent way.

You can ignore an error in Go simply by ignoring its return value. Sometimes it's difficult to tell a foot-gun and land-mine apart.

you can swallow an exception in java by simply having an empty exception case.

Exceptions are certainly more robust, but purposely ignoring errors can be done with exceptions too.

Ignoring errors silently, regardless of intention, can't be done with exceptions.

    try {
        // do stuff
    } except( Exception e) {  
        // ignore
    }

and yes, I've seen it often.

I will agree that it's not possible to accidentally ignore an exception, since it will likely crash your application.

That's not silent, it's screaming in the code.

that's only if you find it in the code

I thought we were talking about code though.

The snippet used in these examples is almost never what you actually write in real code. You will almost always annotate the error, e.g.

    result, err := computeVector(input)
    if err != nil {
        return nil, fmt.Errorf("error computing vector: %w", err)
    }

But that's a bit unwieldy to write in an article or talk.

That's still not error handling.

Error handling would look something like this:

    for err := callService(); err != nil {
        logger.Info("Retrying...")
    }

    value, err := readValueFromFile("abc.conf")
    if err != nil {
        value = getDefault()
    }

etc.

> The snippet used in these examples is almost never what you actually write in real code.

This statement is categorically false, and I would encourage you to search GitHub for `return err` under the Go language.

There are 200k+ code results, and a quick survey of the first few pages shows plain ol' `return err` to be _quite_ common.

You've just removed all of the machine parsable context of the error, guaranteeing that downstream code can't make an intelligent decision.

That's what errors.Is() is for.

No, I didn't.

https://golang.org/pkg/errors

I mean, that's a not in the standard library, and it's a library that's literally already in maintenance mode.

Edit: you also deleted the context of your call. You didn't create an error type for Unwrap to match on. That means that downstream code only has extremely primitive errors to match on, with the context of the call gone. Just because you can track down the EOF error, doesn't mean that code calling this can do anything useful with that. 'Socket closed unexpectedly' is way less useful than 'Unable to update user record'.

Package errors is indeed a part of the standard library.

Yes, they were wrong about that.

But they were right about it losing error context. Basically errorf can only help you bubble up the lowest level error in a machine readable way. You have to write your own error type if you want to let code handle the higher level errors.

That can and should be generated; it's not as if the machine doesn't know which function failed. We don't force human beings to plow through all the rote instructions that set up a stack frame or invoke an object's implementation of a method, and for the same reason we shouldn't force them to plow through the rote instructions that bubble an error toward the handler. When errors exist in your problem domain, manipulating them becomes part of the language's job, and nearly every language from the last thirty years acknowledges that.

One of my pet peeves about Go is a lot of errors are not exposed as public variables, so your options of handling them are somewhat limited other than a generic "something went wrong". I've recently written a tool that classifies various http request errors (think SSL failure, not a 500 status code), and have had to have a deep dive into Go reflection as part of that.

I understand part of this is because they don't want to have to worry about making potentially breaking changes - but what I've had to do means my code will break if the internal API changes, and as it's using reflection the compiler won't catch it. It would be nice to have a "yes I know I shouldn't, but I really want to" (ala Ruby's send method) way of doing this that the compiler will still check.

> You're also making it much harder to tell the code that handles errors apart from the code which doesn't.

Error handling isn't distinct from, or less interesting than, the principal logic of a block of code. Error handling is frequently the most important part of a block of code, especially in the domains that Go targets.

That's not what I meant.

Code that handles an error looks like this:

    if err! = nil {
        if fileErr,ok := err.(MissingFileError); ok {
           createFile(fileErr.FileName())
        } else {
            return fmt.Errorf(...)
        } 
    }

While code that does NOT handle an error looks like this:

    if err!=nil {
        return fmt.Errorf(...)
    }

And the former is less than 1% of the cases I’ve seen from experience. Somehow people have fooled themselves into believing that the language forcing humans to be manual exception bubblers somehow means they have “handled” the error.

Reply on news.ycombinator.com