Hacker News Reader

Absolutely. Even after "compressing" my code as much as possible, it looks as if 2/3 of a Go program is pure error handling and no business logic. I just don't understand this militant objection toward exceptions now. Even back in the days of slower virtual machines and crappier hardware, we were fine, and now it's code red! Get rid of exceptions! Performance!

This is in an era of tech where everyone is building BAD distributed systems, with non-optimized databases, a fur ball of slow HTTP queries, and giant payloads. Exceptions are the least of your concerns.

>it looks as if 2/3 of a Go program is pure error handling and no business logic.

This is exactly why it's good. It forces developers to think about things outside the happy path business logic. And it does this at the point where they know best what such an error could mean.

Proponents of exceptions let their users catch the exceptions they overlooked.

If you ask me Go is not forcing this enough, the ML style Result types in Rust are a much better abstraction here.

> This is exactly why it's good.

How did we manage to get this far before people ~~went insane~~ decided that this is somehow favourable?

After working in an SRE-type role on a codebase full of unchecked exceptions, or exceptions that are caught at the wrong levels because programmers just want their code to work - forcing the explicit handling of errors is favourable because it requires developers to think about what they really want to happen when something goes wrong at this point in the code. Whereas without it, often they will simply catch the exception and continue on silently, or re-raise it without proper context.

Conversely, sometimes there are really simple cases that are totally ignored by programmers because they forget that an exception might be thrown. The worst offender in my experience is in Python where people assume the existence of dictionary keys and get KeyError exceptions, or NoneType exceptions. Without type hints, there's no mechanism to warn you as you write the code that these things could occur. So programmers don't plan for it. If there are explicit errors, the programmer is forced to consider the case that the key they want doesn't exist, or that this variable isn't actually the type they expect (static typing helps here too).

In general, I think this prevents footguns when you are working on large programs. It's worth the verbosity.

See, you perfectly explain why this is the completely wrong approach.

You have a headache and take painkillers, believing it's going to cure it. No, it doesn't cure the headache, it just masks it out.

The cure is teaching people how to actually program the machines. That's all it takes. Decades of abstraction and piling up more and more nonsense eventually led to the situation we are in now, where people praise bullshit which wouldn't be necessary if people had actually learned how to program the machine and how to do it properly.

Instead people need more and more help to do even the simplest things because they've never learned how to do things the right way. So now idiots require tools preventing them from making mistakes they wouldn't be making if they were properly educated!

This is also how errors-as-values work in Rust. Functions that may fail return Result<T, E> - putting an ? at the end of a failable function call returns T on success, otherwise it propagates E. It reduces

    result, err := call()
    if err != nil {
        return err
    }

to

    let result = call()?;

Completely unobtrusive, but makes failure awareness an obligation.

I know about ? in Rust - the one thing that isn't very clear to me is how often it is enough. That is, with Go, it's quite typical to do something like:

  result, err := call()
  if err != nil {
    return fmt.Errorf("Error while trying to call: %v", err)
  }

Essentially manually building a stack trace. If just doing "return err", you end up with calls to a REST service failing with messages like `couldn't parse "" as int` even in internal logs, which isn't helpful. With exceptions (in any language except C++), the stack trace is often decent enough.

Does ? add any kind of context implicitly, or do you have to actually pattern match manually to add context?

if you only limit yourself to the standard library, you would need to unwrap and rewrap the error - although admittedly since Result<T, E> is a type like any other, you could add an extension function (through a trait) so that you can add context more easily. If you use use one of the error handling libraries though, you're in luck - adding context is usually a single function call away:

    //without context
    some_function()?;
    //with context, using anyhow
    some_function().context("function returned error")?;
    //with wrap_err, using eyre
    some_function().wrap_err("function returned error eyre")?;

There is not (normally) context added automatically. One can use `map_err(|e| ...)` to add context like this:

    let result = call().map_err(|e| SomeError::MoreData(e))?;

Or if using one of the common error libraries to have non-specific error kinds:

    let result = call().context("some data")?;

or

    let result = call().with_context(format!("something happened: {}", other_thing))?;

For something that more directly matches the behavior of the go code, this (using the `anyhow` crate) is a possible match:

    let result = call().map_err(|e| anyhow::Error::msg(format!("Error while trying to call: {:?}", e)?;

Though one would normally avoid this when using anyhow (or in rust in general) as it means we're flattening the error instead of generating a list of causes.

Absolutely agree with you on that front. Go's tedious error checking and manual rewrapping is pretty annoying and I'm sure there's a smarter way to do things waiting to catch on. That being said, I prefer that annoyance over the horrors of working in a codebase where exceptions are used for control flow, not checked at all, or just treated as an afterthought. In my experience, those programs tend to be fragile, often crash with little context, or just silently continue after a failure. At least Go forces you to deal with it.