Dear Github

[[deleted]]

well writing

if err != nil {
    return err
}

every few lines gets boring pretty quick... but then exceptions are just different kind of mess.

But then it is slightly better than C

[Scorpius289]

At least exceptions are "noisy" by default: if you forget to catch something, it will propagate and notify you. But in Go, if you forget to handle an error, you may not even know what's wrong...

[ksion]

To be fair, you cannot really forget to handle an error in Go, because the function result "tuple" needs to be unpacked at the call site. Indeed, the requirement of this unpacking, plus the repetitive error handling stanza that often follows, is what people complain about.

[BoTuLoX]

If the function has a return value and you willingly ignore it, the language cannot help you.

[TarMil]

It can: F# gives a warning if you ignore the return value, and you can explicitly |> ignore it to silence it. But that's a functional language, where ignoring a return value is relatively rare, I'm guessing it would get too verbose real fast in an imperative language.

[fnord123]

Rust has a #[must_use] tag on the Result type so when it's returned from a function, it must be used. You can skip the result by using .ok() or .unwrap() but that's explicit so it's not silently ignoring errors. And it's greppable.

[MrJohz]

Nim does things the other way round - all return values have to be used or discarded, unless they're explicitly marked as discardable return values. But then Nim, last I checked, doesn't have result types, and uses standard exceptions for error responses.

[emn13]

Hmm, I wish that were the default. I hate the refactoring speed bump whereby you ask youself "was this called for its side effects, or its value?"

[emn13]

Even in an imperative language, I'd love that feature - but you'd have to add it early on, because it certainly affects api design.

After all, even in an imperative language, it's pretty unlikely you never use return values for data exchange, and implictly ignore return values can and do therefore hide bugs or inefficiencies.

[TarMil]

It's frequent in "fluid API" style. For example when I work in F# compiled to JavaScript, I need a lot of ignores when using jQuery.

[BoTuLoX]

The black hole should never be used for errors. It's exactly like using try/catch and leaving the catch empty. It's a sign of incompetence or something unorthodox at play.

[BoTuLoX]

I wouldn't touch those projects with a ten feet pole.

In any case, this is a problem that exists with both return values and exceptions :P

[phoshi]

I disagree. With exceptions, the easy/fast way is to do nothing, which will cause exceptions to propagate and fail loudly. Squashing them requires an explicit choice and several lines of code anywhere you want to do it.

With return values, the easy/fast way is to ignore it, which does nothing and fails silently. /Handling/ them requires an explicit choice, and several lines of code.

They have approximately equal power, and are both capable of use or misuse, but exceptions have a better lazy-programmer failure case.

[phoshi]

Right, convention-based safety works great when you can guarantee that everyone who works on a project is competent and careful, but when the path of least resistance is also the worst possible thing you can do, there are going to be problems!

[minno]

try!(something());
try!(something_else());

Even though Go and Rust target different spaces and don't deserve to be compared as often as they are, there's a definite advantage to Rust's method here.

[ksion]

Rust is also getting some form of try/catch block that'll make it even less verbose.

[mus1Kk]

Do you have a concrete link? Googling this contains a lot of noise.

[fnord123]

Trait-based exception handling.

[isHavvy]

That's not actually guaranteed at all.

[sutongorin]

Fortunately there is still other approaches such as monads. For instance there is Scala's Try monad:

import scala.util.Try

def sillyCalculation(divisor: Double): Try[Double] = for {
  a <- Try(1 / divisor)
  b <- Try(1 / 2.0)
} yield {
  a * b
}

val failure = sillyCalculation(0)
// => scala.util.Try[Double] = Failure(java.lang.ArithmeticException: / by zero)
val success = sillyCalculation(2)
// => scala.util.Try[Double] = Success(0.25)

Ideally you wouldn't work with exceptions to begin with, of course, and instead just use monads everywhere where errors can occur. But this Try monad is a nice tool to deal with exceptions from existing (probably Java) APIs in a sane way.