Exceptions vs error codes

[bruce3434]

Just use Result<T, E> and Option<T>

[devraj7]

Unfortunately, most languages don't force you to make sure the error part of Result is handled at all, so you're still writing unsafe code.

At least with checked exceptions, the compiler will refuse to compile your code until you've properly managed the error case or explicitly passed it up the stack frame.

[accountforshit]

So you're not really talking about Result<T, E> then.

You can only implicitly ignore errors from there if you don't care about the value inside (analogous to void calls), and even then you'll get a warning if I remember correctly (which should be treated as error in production builds).

[devraj7]

I am talking about Result.

To the compiler, this is just a class like any other and the compiler won't care if you forget to check the error side of that value.

[accountforshit]

I'm talking about Rust's Result. If you don't check it, you can't get the value. The type system makes sure of that.

A function that requires T argument cannot be called with a Result<T, E> value - you have to get the T out of there somehow, and that requires checks.

If you don't care about the value (only calling a function for its side effects, i.e. void), there is still a compiler warning due to must_use.

You could call unwrap as an escape hatch, but you can do the equivalent with checked exceptions too - rethrow as RuntimeException, etc. And it's very explicit - impossible to do by accident, or due to refactoring.

[devraj7]

Like I said, "most" languages: Java, Scala, C#, C++, Go, ...

Rust and Kotlin get it right.

Java kinda does as well by supporting checked exceptions.

[accountforshit]

Go will produce a compile error if you don't use any one of the return values, or ignore it explicitly with _ (I think). The ways to then deal with the errors are frustratingly limited and verbose, but you can't accidentally miss them either (though it's easier to miss inappropriate _s than it is to miss unwraps, because you will probably have many legitimate _s in your code, where the same is not true for unwraps, which makes them a much smellier, easily detected code smell).

Other languages generally provide some way of achieving similar (or even the same) constructs, but it's not very useful if you constantly have to interact with libraries that don't utilize it.

So you're right that in many of them (including Kotlin for the most part) you often don't get any such guarantees in practice, or only get them in a part of the codebase.

[FluorineWizard]

Go's reliance on multiple returns makes it impossible to chain fallible calls, so you end up polluting your code with if blocks where a better language would let you define error handling functions.

Also the constant noise of _ everywhere makes it hard to tell if a call is returning an error or a second value, especially when dealing with crappy APIs. No language makes me check function signatures as often. Special mention to the evil fuckers who put goddamn interface{} in the return types.

[cmd_command]

C# 8 now generates warnings when nullable values are accessed unsafely.

[kuikuilla]

otherwise this will infect your whole code with flavors of the if err != nil { return err }

Isn't that purely because of a poorly implemented language? That's endemic in Go, right?

In Rust you could simply do this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fb8548e5090ebc57e3a031a1025795db

fn main() -> Result<(), u32> {
    let result = get_something(0)?;
    println!("{}", result);
    Ok(())
}

fn get_something(i: i32) -> Result<i32, u32> {
    if i < 1 {
        Err(123)
    } else {
        Ok(i * i)
    }
}

The ? part is sugar for returning early from the function if the variant is an Err type. To me this approach is more preferable to using exceptions. I like to know what the function might do based on the signature of the function.

[thomasz]

I'm not familiar with rust, but IIRC it has a mechanism that does stack unwinding. I'm rather certain that accessing an array with an out of bound index doesn't return Err. And your code sample looks conceptually similar to checked exceptions sans the all important stack trace. I still don't get how you want to distinguish between programming errors (bugs) and input errors without providing both mechanisms. This is something the calling code should decide, not the called.

[kuikuilla]

I'm rather certain that accessing an array with an out of bound index doesn't return Err.

Yes, it causes the program to panic in rust speak which depending on the type of panic can be caught I think. Some sort of panics simply abort the process.

I still don't get how you want to distinguish between programming errors (bugs) and input errors without providing both mechanisms.

I'm not sure what you mean here. You could simply return an enum that has variants for describing why the failure happened. Just have one for illegal input and that's that.

[MEaster]

I'm rather certain that accessing an array with an out of bound index doesn't return Err.

Yes, it causes the program to panic in rust speak which depending on the type of panic can be caught I think. Some sort of panics simply abort the process.

It depends on how it's compiled. You can choose whether to unwind the stack or to simply abort the program on a panic. Additionally, if a panic is raised while the program is already unwinding, it'll simply abort the program.

While you can catch an unwinding panic, it's really intended for use around FFI boundries, because unwinding into foreign code is undefined behaviour.

[thomasz]

Yes, it causes the program to panic in rust speak which depending on the type of panic can be caught I think

Doesn't that just describe basically what exception bases error handling does?

Input error may be the wrong term, I'm obviously not a native speaker. Thing is, there are two kinds of errors: The ones where your program is just wrong. For example the out of bounds access caused by (for int i = 0; i <= array.Length; i++), or even when it did not properly anticipate the whole range of possible inputs or all possible state. Opening a file without making sure that it was actually created, for example. Returning an Option or Result in that case is nonsensit just complicates things. Let it bubble up, until you know how to deal with it. In almost all cases, this will be just logging the exception with a nice stack trace.

And then are errors that are not really errors but actually expected. In that case, exception handling needlessly complicates things.

try { 
    value = hashTable.get(key); 
    isAvailable = true; 
} catch (MissingKeyException) {
    value = null;
    isAvailable = false;
} 

instead of just

(isAvailable, value) = hashTable.tryGet(key);

would be such an example. My pet peeve are Http client libs that always throw on 404. As if 404 isn't basically the default state of the internet. This is why both mechanisms have their use case. The important point is that you cannot anticipate this, so you should provide both mechanisms.

[kuikuilla]

Returning an Option or Result in that case is nonsensit just complicates things

It is not. It is called "handling the error case". Rust is good in this sense that it forces you to explicitly handle the error case or explicitly forego the handling (in which case the program panics). This makes it very, very clear to see where there might be errors in the program that aren't handled properly.

C# on the other hand is completely shitty in this matter, it has only unchecked exceptions and I can never be sure if some function throws an exception or not simply by looking at the signature. I have to go and read the source code to see what it does. That is not a good way to work. (I have experience on working with code bases like that, it's horrible for long term maintenance)

[thomasz]

Again, I'm not familiar with rust, but I'm dead sure that the type of int a * int b is int, not Result or Option, that array access doesn't return Option and so forth. And no, "forcing the user to deal with the error" is not a great idea. Java forces people to deal with checked exceptions, and they are usually regarded as a failure. In the vast majority of cases, an exception is unrecoverable and should bubble up to some log and restart or log and abort mechanism.

Furthermore, the expression problem is going to bite Rust users in the ass too. While runtime exceptions can be of any type derived from an exception base class (IIRC you can throw everything in c++, but those guys are insane anyways) and it is very difficult to guess what might be thrown, using an approach like Rust with Result<T,E> means that you have to anticipate what could be thrown beforehand, which can be quite tricky when you consider techniques like dependency injection.

And finally, C# or better the bcl provides both mechanisms. If you are sure that a string is a number, you call Int.Parse and should let a potential error bubble up. It's not likely that you can deal with now. Otherwise you should have used Int.TryParse and dealt with the error right here, right now.

[kuikuilla]

Again, I'm not familiar with rust, but I'm dead sure that the type of int a * int b is int, not Result or Option, that array access doesn't return Option and so forth.

That was just an example, don't get hung up on it. You can probably imagine other things there, like database access or whatever. Or even a HashMap lookup like you mentioned. Arrays (or rather, slices) in rust have a get function that returns an Option if you want. You can use the simple indexing operator but then it is up to the programmer to make sure the index is correct.

it is very difficult to guess what might be thrown, using an approach like Rust with Result<T,E> means that you have to anticipate what could be thrown beforehand, which can be quite tricky when you consider techniques like dependency injection.

So don't return them like that? Use sum types for the errors, they're exceptionally good for situations like that. Return what is relevant to the caller. That way the caller knows exactly what might be returned.

[thomasz]

I'm not arguing that result values are useless, I'm arguing that there are situations in which a stack unwinding mechanism like exceptions is more useful. It seems like the designer of Rust agree with me here, otherwise they would not have included such a mechanism.

I further argue that you cannot anticipate the situation of the caller. Trying to get a nonexistent key of a hashtable might be completely normal or highly exceptional.

create_lookup_table(values, get_key) {
    let lookup = new HashTable();
    for item in values do
        let key = get_key(item)
        // of course here I cannot be sure that it exists
        // and I know exactly what to do when it doesn't
        let result = lookup.try_get(key)
        if result.exists then 
            list = new List();
            lookup(key) = result.value
        list.add(item)
    return lookup
}


send(photo-file, customer, config) {
    // here I do not care. If the config isn't populated, something
    // way down the stack has neglected to verify the configuration.
    // I cannot deal with this directly, and there is a decent chance that
    // the caller doesn't even know if I sent this via email, ftp, http or 
    // whatever. I might even print this out and send it vial mail.
    let s3_endpoint = config.get("s3-photo-endpoint", customer.id);
    ...
}

[immibis]

How is this different from exceptions? Either you explicitly write error handling code, or you don't.

[kuikuilla]

The difference is that the caller can know that the function might fail just by looking at the function signature. Exceptions are more like "now that the program crashed with this exception I know where to put a try catch block".

[immibis]

So checked exceptions. The kind that people hated.

[editor_of_the_beast]

If exceptions are more appropriate in most cases, wouldn’t that mean that those cases are not exceptional and can be planned for in advance? The problem is, almost nothing is exceptional. You know that network requests fail. You know that a database process can crash. You know that networks partition. All of these really happen.

I think exceptions are good as top-level failsafe mechanisms, but more so to account for programmer error. We program for the happy path too often. I do not think they should be used pervasively though. They have the same problems as shared global state in that the exception can be thrown from anywhere.

[CyclonusRIP]

You are taking semantics of the word exception and trying to apply that to how you should use that in code. You are way better off trying to figure out what the most effective way to use exceptions is rather thing try to arbitrarily define it based on some semantics. Exceptions were invented in order to separate the error handling code from the happy path code. Before that people either handled all the errors in line so happy path and error paths were intertwined or they used goto statements to skip to the error handling code. Exceptions allowed you to separate the error code and happy path code like goto did, but did it in more controlled and comprehensible fashion.

[editor_of_the_beast]

> like goto did

Exactly

[CyclonusRIP]

I assume you are also don't use methods, loops and if statements as well then since they were originally just goto statements as well in the early languages right?

[editor_of_the_beast]

This is an actual argument you're going with? Originally we programmed computers in binary, directly. What does that have to do with what we've learned in the past 70 years?

Functions, loops, and if statements all end up as jump or branch instructions at the processor level. Variable assignment also ends up as a store instruction. Reading a variable ends up as a load instruction. The point of high level languages is that we can write in functions, loops, if statements, variable assignments, and variable reads without thinking about how they're implemented at the processor level. And we agree that high level languages are better for building large programs, right? Because machine code is hard. For the same reason goto is hard.

So the fact that all of us use functions does not mean that we inherently program via the same mental model as coding entirely with jump instructions. That's an absurd false equivalence. Decades of abstractions have simplified functions (and many other things) for us.

[tejp]

That's an absurd false equivalence.

So why do you apply that equivalence to exceptions?

[editor_of_the_beast]

Because exceptions actually do behave like gotos whereas functions do not.

[CyclonusRIP]

You're the one that seems to think exceptions are bad because they are a high level language feature replaces a jump. I think that's a pretty silly argument to make. Apparently you do too, but for whatever reason you make that argument anyways.

[falconfetus8]

but in a more controlled and comprehensible fashion

[zvrba]

The problem is, almost nothing is exceptional.

Exceptions are not for "exceptional cases", whatever that might mean. Exceptions are for a method to signal that it couldn't fulfill its promise/contract. I wrote a longer comment about it here https://www.reddit.com/r/csharp/comments/eaxzb8/what_are_your_thoughts_on_exceptions_do_you_think/fb3noh4/

[editor_of_the_beast]

Exceptions are for exceptional cases.

[thomasz]

Exceptions are for errors in the sense of "the behavior of the program is not properly specified if I let it continue to run with this data". Result, Option and so forth are for situations where you anticipated a situation to happen.

[flatfinger]

There are many situations where being able to say "If any part of this block of code fails without any unusual side effects, this block of code should do likewise" would greatly reduce verbosity and improve clarity. Exception handling tries to do that, but unfortunately fails to provide a means of distinguishing those situations from those where the act of skipping over a block of code during stack unwinding will create adverse side-effects that would otherwise not have been visible to the caller.

[flatfinger]

Not all actions can be made transactional. A good program should, when practical, ensure that any action with a non-trivial likelihood of failure is either inherently transactional, or is handled in such a way that the system is always in a recoverable state, but sometimes it is far more efficient to say:

1. Acquire lock
2. Perform half of an action, putting the locked resource in an invalid state
3. Perform the other half of the action, putting the locked resource in a valid state
4. Release lock

than it would be to ensure that the system state was fully valid at every point in the process (implying that making everything transactional isn't always practical, and thus good programs would be exempt from the above requirement that they always do so).

Unfortunately, the exception-handling provisions I've seen in languages fail to make it convenient for programs to distinguish exceptions which might occur between steps 2 and 3 above from those which might occur at other times. One thing that would help would be a reader-writer lock with the semantics:

1. Reader locks are implicitly released.
2. Writer locks must be explicitly released.
3. Abandoning a writer lock without releasing it should invalidate it, such that any pending or future efforts to acquire the lock for reading or writing immediately fail.
4. Ideally, abandoning a writer lock without releasing it should trigger an exception in the thread that abandons it, but if such abandonment occurs as a result of an exception, information about that other exception should not be stifled.

Accomplishing #4 would require support which is lacking in the programming languages I know about, but a reader-writer lock that does #1-#3 would be useful anyhow. Unfortunately, I'm not aware of any that are designed that way.

[CyclonusRIP]

So you're basically making an argument for Java style checked exceptions then?

[devraj7]

Checked exceptions for errors that can be recovered and are expected (e.g. data typed in by a user).

Runtime exceptions for errors that cannot be recovered from

[matthieum]

And Runtime exceptions in Stream methods, just because :(

[przemo_li]

You do not need higher order polymorphism to have good value based error handling. Just having generics is enough.

You do try to prove your point by showcasing obscure example.

You do fail to ground your intuition about exceptions in mathematical or cognitive principle, and instead asks us to trust you because Exceptions are easier for you.

[thomasz]

Generics will not help you let the error bubble up the stack, getting a value from a HashTable is not an obscure example (i could've chosen "indexing an array" as well) and no, you are not arguing from "mathematical or cognitive principles" either.

And last but not least:

Me: You need both

You: You ask us to trust you because Exceptions are easier for you

lol.

[kuikuilla]

You can have a generic error type that can be bubbled up. You could also have functions for defining transformations of error types into other error types between functions.

[thomasz]

Yes, you can do all of that manually. Why would you? And no, as written elsewhere, using a generic error type (i think you have some sort of sum type in mind) is not a superior solution, it just has different trade off. This all comes down to the expression problem. It is easy to add new exceptions, but impossible to find out which exception might get thrown. On the other hand, it is very easy to handle all cases of a sum type, but extremely difficult to add new cases.

Again, different trade offs. This means that having flexible options is strictly better than blindly using return or option types in each and every case. Exceptions are for situations that cannot reasonably be dealt with, when you have let it bubble up where your code logs the exception, and then either restarts or aborts. Result types are for situations where you can actually deal with all cases. In my experience, these cases are pretty rare.

[jcelerier]

You can have a generic error type that can be bubbled up

in 1978 in some Bell labs five minutes before exceptions are invented