TooMuchAbstraction posted:

I fail to see how this is any worse (or better) than the Go equivalent:

code:

foo, _ := thingThatCanFail(); // second return val is an error, but who cares?

The thing that bugs me most about Go's error handling is that you don't get stack traces out of it. Like, the zero-effort thing to do with exceptions is just let them propagate up to a top-level exception handler, which then says "hey, this function buried ten levels deep in your program tried to use a dead network connection on line 128 of db.java, you dumbass." Whereas in Go you have to do stuff like this for every single function call:

code:

if err := doAThing(); err != nil {
  return fmt.Errorf("couldn't doAThing: %s", err)
}

And then you get to decipher the corresponding top-level message: "couldn't process request: couldn't retrieve customer details: couldn't get customer ID: couldn't doAThing: database connection went away". And if you don't write a little description for each error, and instead just return the bare error, then you get errors like "couldn't process request: database connection went away", which is absolutely inscrutable.

Languages should make it easy to do the right thing. But far more important than making it easy to do the right thing is making it harder to do the wrong thing. Go's mistake here is that the mechanism it came up with becomes useless when misused, and misusing it is what lazy programmers are going to do because it saves them a little typing/thinking in the short term.

Coffee Mugshot posted:

I don't why people refer to Rob Pike so much when he hasn't worked on the project for like a year at this point.

quote:

I was working at Google when Go started to come out, and this was exactly the response I got from Rob Pike when I asked about error handling.
Basically, I felt that only doing error handling through return codes was dangerous and bulky.
It's dangerous because there's no way to enforce that callers check that return code, and worse, because if I add a return code to an existing function, I have no way to make sure that existing callers check that return code.
It's bulky because, in a mature program, many subroutine calls have the possibility of errors, so almost every subroutine call needs a manual error check, which then propagates up to all callers too. I feel bulky, repetitive code is bad because both the programmer and the reviewers get tired when reading it and start to skim the details.
Pike's response was, "Don't do that." Basically, developers should always check error codes, and they're just dumb if they don't; and I should never add an error code to a function that didn't have one before. And regarding bulky, well, that wasn't even considered an issue by Pike.

KernelSlanders posted:

What "unequivocally better solution" are you referring to?

Please don't say exceptions because those are also horrible and go recognized the problem, but like everything else in that language the attempted fix fell way short of its potential.

comedyblissoption posted:

One imperative alternative to go's error handling that doesn't use exceptions is the way Rust does it with sum types. In Rust, errors are expressed as Result<TSuccess, TError>. A value must either be a success or a failure. These states are mutually exclusive. You are forced by the language to handle both cases. You cannot forget the error situation if you want access to the success value. A return value that may have an error has a different type than a return value that cannot have an error. If you change a function return signature to return an error when it did not before, the compiler will let you know all of the call sites that are now broken as a result. You cannot have garbage non-sense values that you are by convention supposed to ignore like in Go.

Rust also has syntactic sugar for the common case of just propagating the error up the call stack.
https://doc.rust-lang.org/book/second-edition/ch09-02-recoverable-errors-with-result.html

code:

use std::io;
use std::io::Read;
use std::fs::File;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut s = String::new();

    File::open("hello.txt")?.read_to_string(&mut s)?;

    Ok(s)
}

Every ? in that example will propagate an error to the caller. If there was no error, then the expression will result in the success value. Handling errors as values instead of exceptions does not require golang-ish boilerplate.

comedyblissoption posted:

Plorkyeran posted:

Are you feigning confusion here or are you really in that much of a bubble? Rob Pike was the public face of Go for most of the language's public existence.

JewKiller 3000 posted:

pattern matching over algebraic data types

Coffee Mugshot posted:

I hope you write code that’s less obtuse and snarky that your posts. Spell it out for us that are too daft to understand how simple it is.

comedyblissoption posted:

One imperative alternative to go’s error handling that doesn’t use exceptions is the way Rust does it with sum types. In Rust, errors are expressed as Result<TSuccess, TError>. A value must either be a success or a failure. These states are mutually exclusive. You are forced by the language to handle both cases. You cannot forget the error situation if you want access to the success value. A return value that may have an error has a different type than a return value that cannot have an error. If you change a function return signature to return an error when it did not before, the compiler will let you know all of the call sites that are now broken as a result. You cannot have garbage non-sense values that you are by convention supposed to ignore like in Go.

Rust also has syntactic sugar for the common case of just propagating the error up the call stack.
https://doc.rust-lang.org/book/second-edition/ch09-02-recoverable-errors-with-result.html

code:

use std::io;
use std::io::Read;
use std::fs::File;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut s = String::new();

    File::open(“hello.txt”)?.read_to_string(&mut s)?;

    Ok(s)
}

Every ? in that example will propagate an error to the caller. If there was no error, then the expression will result in the success value. Handling errors as values instead of exceptions does not require golang-ish boilerplate.

Coffee Mugshot posted:

I see, you're just talking about variant types in general being used for errors. Probably wouldn't work well with Go interfaces if one of the variants is an interface itself. How does rust handle this?

Coffee Mugshot posted:

If you dislike Go because Rob Pike was an rear end in a top hat, it's unlikely you've had enough time to actually consider reasonable applications of the language.

Asymmetrikon posted:

Disliking a language because one of its loudest designers is a shithead is actually entirely reasonable.

vOv posted:

I'm a pretty big fan of explicit error values like in Rust but the one problem with them, like was mentioned upthread, is stack traces. I know that the error-chain crate which does a lot of macro hackery to make error management easy also generates backtraces, which seems nice, but I've never used it in anger so I have no clue how well it works in practice.

Boris Galerkin posted:

So you create some verification and validation test cases with well defined inputs and known, exact, outputs. It's not rocket science, but it could be if that's what you're simulating.

Boris Galerkin posted:

I come from a numerical computing background so my bread and butter are C and Fortran (and lately C++ and Python) so I have no idea what error handling is and in fact I'd rather not have my compiler or interpreter handle errors for me. I want my compiler to produce code that is true to what I wrote with exceptions to automatic optimizations, which I will request iff I want, and no funny business going on under the hood. If there are errors it should either segfault when appropriate or return error codes and exit instead of making any assumptions about what it thinks I intended.

Anyway that's my story.

Boris Galerkin posted:

You haven't lived until you've used an obscure library written in FORTRAN77 that's been "forked" three times with hacked together "it works don't touch this I'm serious" features.

Boris Galerkin posted:

I come from a numerical computing background so my bread and butter are C and Fortran (and lately C++ and Python) so I have no idea what error handling is and in fact I'd rather not have my compiler or interpreter handle errors for me. I want my compiler to produce code that is true to what I wrote with exceptions to automatic optimizations, which I will request iff I want, and no funny business going on under the hood. If there are errors it should either segfault when appropriate or return error codes and exit instead of making any assumptions about what it thinks I intended.

Anyway that's my story.

Boris Galerkin posted:

I come from a numerical computing background so my bread and butter are C and Fortran (and lately C++ and Python) so I have no idea what error handling is and in fact I'd rather not have my compiler or interpreter handle errors for me. I want my compiler to produce code that is true to what I wrote with exceptions to automatic optimizations, which I will request iff I want, and no funny business going on under the hood. If there are errors it should either segfault when appropriate or return error codes and exit instead of making any assumptions about what it thinks I intended.

Anyway that's my story.

Boris Galerkin posted:

I come from a numerical computing background so my bread and butter are C and Fortran (and lately C++ and Python) so I have no idea what error handling is and in fact I'd rather not have my compiler or interpreter handle errors for me. I want my compiler to produce code that is true to what I wrote with exceptions to automatic optimizations, which I will request iff I want, and no funny business going on under the hood. If there are errors it should either segfault when appropriate or return error codes and exit instead of making any assumptions about what it thinks I intended.

Anyway that's my story.

Jeb Bush 2012 posted:

apparently not, because "making assumptions about what it thinks you intended" is not what people mean by "error handling"

good error handling stuff does the same things as "segfaulting when appropriate" or "returning error codes", but in ways that are less prone to, well, error (relying on segfaults for error handling is particularly nuts because segfaults are non-deterministic and any time your program could segfault it could do something horrible and undetectable)

Boris Galerkin posted:

Well in my opinion sqrt(2) is an error because the argument is an int and the return is a real. I'd prefer it give me an error outright, rather than assume I meant to do sqrt(2.0), even though I most likely did.

Boris Galerkin posted:

Ok now I'm being serious because I don't understand/know: what would you have it rather do? If the node index was out of range then it should attempt to read memory it can't read and crash, that's how I see it. The other options would be "assume user meant to access last index" or "ignore this error and keep going." Both seem like terrible options to me.

Boris Galerkin posted:

Ok now I'm being serious because I don't understand/know: what would you have it rather do? If the node index was out of range then it should attempt to read memory it can't read and crash, that's how I see it. The other options would be "assume user meant to access last index" or "ignore this error and keep going." Both seem like terrible options to me.

e: If you say "it should just note the error and exit it gracefully" then well I just don't see the point/how that's different than just segfaulting. It's not like I can do anything about it other than fixing the problem and recompiling/rerunning.

quote:

http://www.netlib.org/lapack/lug/node119.html
All documented routines have a diagnostic argument INFO that indicates the success or failure of the computation, as follows:

INFO = 0: successful termination
INFO < 0: illegal value of one or more arguments -- no computation performed
INFO > 0: failure in the course of computation
All driver and auxiliary routines check that input arguments such as N or LDA or option arguments of type character have permitted values. If an illegal value of the ith argument is detected, the routine sets INFO = -i, and then calls an error-handling routine XERBLA.

The standard version of XERBLA issues an error message and halts execution, so that no LAPACK routine would ever return to the calling program with INFO < 0. However, this might occur if a non-standard version of XERBLA is used.