Hacker News Reader

Comment by mindwok | Hacker News Reader

Exceptions are starting to feel like a legacy programming paradigm to me. Rust & Go have, at least in a practical programming context, shown that errors-as-values has far less footguns and encourages better error handling practices than exceptions, which often are treated as an afterthought or end up being abused like in this post.

Whenever I'm writing Python or Java I can't help but feel anxious about calling a function and having absolutely no idea if or what exceptions it might throw, and then having to resort to digging through documentation or class hierarchies to figure it out.

View on HN

At least for Go (haven't used Rust), I entirely disagree. After ~3 years of professional programming with the language, `if err != nil` is still constantly annoying me when writing code, but especially and most importantly, when reviewing code.

Not to mention, Go has proven conclusively to me that exceptions are exactly the right pattern for error propagation - the 99.9% pattern is "function returns error with message; callers add context; top-level caller aborts and logs + returns message to user, or sometimes retries". This is exactly how exceptions work out of the box, without the need to pollute all code between the error source and the top-level caller.

If anything, I'd like to see a language seeking to add smarter information to exception stack traces - not just the function + code line, but also some information about local variables might be doable, and would supplant the one occasional gap between Go-style hand-built context and Java/Python auto-generated exceptions.

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
    }

    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")?;

    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. 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!

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.

I think what Java got wrong was allowing catching unchecked exceptions. If Java had only allowed recovering from checked exceptions, it would have been a very similar experience to Rust's Result and panic.

Instead, the trend was to avoid using checked exceptions at all, which perpetuated the crazy situation we're in where library code can suddenly abort and the author shrugs and says "shoulda read the docs".

> I think what Java got wrong was allowing catching unchecked exceptions. If Java had only allowed recovering from checked exceptions, it would have been a very similar experience to Rust's Result and panic.

> Instead, the trend was to avoid using checked exceptions at all

Java's type system was far too weak for that to be at all practical. Early Java not only didn't have first-class functions, it didn't even have generics. Even today checked exceptions are horribly cumbersome - for example, it's simply not possible to write a wrapper function that accepts a function and calls it, and throws the same set of checked exceptions that the inner function does.

If Java had had proper ML-style types from day 1, like Rust does, then it could have done "errors are values" in a practical way. But forcing people to use checked exceptions would have resulted in either C-style errno codes, or the whole language collapsing under its own weight.

Yes, checked exceptions with a proper type system and abstraction facilities would be completely equivalent to Result<T,E>, except built into the language.

> it's simply not possible to write a wrapper function that accepts a function and calls it, and throws the same set of checked exceptions that the inner function does

It is possible, and straightforward, to do that if the set of checked exceptions is of a statically known size, and the wrapper function can propagate the exceptions rather than catch and rethrow them. In my experience, that is a very common situation (although not universal).

If you want to catch and rethrow, that can also be done, but it requires an evil hack, and the wrapper will need to take a reified type for the exception.

That's fair. Lack of inference is also a huge problem with Java's checked exceptions.

My point is less that Java could have done this differently with the other type choices that they made and more that it's a shame that Java's implementation of checked exceptions has poisoned the concept for so many. I think a language with strong type inference and a checked exception mechanism would be better than Rust's Result type because you get the stack trace.

> where library code can suddenly abort and the author shrugs and says "shoulda read the docs".

In see no difference. Except for the fact that you don't have the stacktrace (in Go), and unroll the Stack manually. In any case, there'll be a generic catch (whatever you call it) on the top level of your daemon to recover from the failed request and handle the next.

In Go the programmer is forced to make a decision on what to do with the error. Common patterns include (A) return an annotated error, (B) log it and continue, (C) retry, (D) aggregate the errors in some way. If you believe the only way to handle an error is (A), then Go's design makes no sense.

You seem to believe options B to D are not available to programmers in languages with exceptions. The real value comes from making option E much more unlikely: ignoring both the result and error value altogether, because you relied on the side effect of the function you called.

You might like how Rust does error handling. Rather than a function returning a triple of (val, error) where the error can be ignored, functions return Result<T, E>. If you want to get the T, you must write code that handles both possibilities. If your function instead wants the T and propagate the E upwards if it exists, you can do that with one character - “?”

I indeed like Rust's approach a lot more than Go's. What I like less still is that it gives the impression that it's even possible to define functions that cannot fail. This is not true. One just has to look at how runtimes deal with stack overflow errors to see how the good old Java RuntimeException creeps in in various forms (e.g. panics) because checked exceptions and it's recent incarnation as error values are a leaky abstraction.

Rust makes a distinction between recoverable and unrecoverable errors. Recoverable errors are the E in Result<T, E>. You can take action and recover, depending on what kind of E it is.

Unrecoverable errors are things like stack overflows or out of bounds array access. There is no reasonable way to soldier on after this, so the program should just end. Trying to continue the program in such situations only leads to pain. Like array accesses out of bounds that allow you to read unrelated memory.

But it’s still an evolving area. For example, failure to allocate memory - is that recoverable or unrecoverable? Initially it was thought that it was unrecoverable, and programs would panic if memory failed to allocate. This seemed reasonable, until folks tried to use Rust within the Linux kernel. Within the kernel, failure to allocate memory is recoverable. Rust is evolving the semantics here.

All this to say, yes, Rust does allow you to define functions that either fail in a recoverable way, in which case the calling function should handle it. Or they fail in an unrecoverable way in which case there’s nothing the calling function can do to recover. Thankfully, panics in third party code are relatively rare so this doesn’t happen in practice.

> Unrecoverable errors are things like stack overflows or out of bounds array access. There is no reasonable way to soldier on after this, so the program should just end

No, I wholeheartedly disagree with this. It's the equivalent of exit(1) some way down the stack. Whats recoverable or not depends on the use case and is a decision to be made by the caller of a function, not the implementor.

GP might have been referring to undefined/invalid behaviour (whether in the language or in some OS syscall or whatever). After the demons came out of your nose you can never fix the problem, so there is no point trying to handle the error.

Otherwise I agree with you, that library code should not fail/crash/exit(1) just because of some judgement about recoverability, and out to clean up after itself before passing control back to the caller. If the user wants to fix some ENOSPC deep in my library by shelling out to "rm -rf /" and then trying again, that's fine by me, and this should be reflected in the API.

GP might have meant undefined behavior, but specifically mentioned stack overflows and out of bounds array access as unrecoverable errors. These sound brutal, but are in fact all but undefined. Proper handling is expected in the large class of applications which run as servers.

> it gives the impression that it's even possible to define functions that cannot fail

Do you mean that e.g. an out-of-bounds error will panic? If that's the case, you can always access arrays/slices with some checked access, that will return a Result/Option and cannot panic. But it would be a PITA if you couldn't skip that.

I mean stack overflows or out of memory errors. It might fail one request, but no reason to fail all others.

That's a very specific case, that could be handled non-trivially.

Usually your HTTP framework will already have this implemented, i.e. a panic in a request handler will be "caught", converted to some 500 response, and should not affect other requests.

My point is that this is in no way different from any other class of errors, _except_ in those cases where it is. It's practical to assume all errors are handled like this, because this catch all needs to exist anyway. And unless you have _very specific needs_, this can be automated.

I think conflating these two into one paradigm is worse. The catch-all (exceptions) style is nice only for a few very specific cases, like the request handler example. Everywhere else I want to either bubble up (like exceptions, but Result<> and ? sugar is as good or better), OR I want to handle the error. For the latter case, exceptions are not good at all.

IMHO, quite often when you're tempted to handle an error, you're either wrong to do so, or in some kind of infrastructure glue code. A request handler, a task executor, a strategy chain, a retry loop, you name it. And this code needs to deal with both classes of errors anyway to be bugfree.

From those examples, I think only request and task should deal with panics. Things that start threads or processes.

Other points of "catch all errors" don't need that. And then there are a lot of places where you do handle errors, if they are conceptually a Result. I know you can just catch SpecificError, but the ergonomics are just horrible in terms of control flow.

I don't think threading is relevant to this.

> there are a lot of places where you do handle errors, if they are conceptually a Result

Yet, what's conceptually a result lies in the eye of the beholder, and should not be dictated by an API designer IMHO. Rust's ? is a step in the right direction, but I'd argue since you care about specific errors in maybe 0.1% of invocations tops (in production code), and that's a stretch, the ? should actually work the other way round. And if the mechanism does not provide a way to select specific errors (such as a proper catch clause) the errors it exposes as a result should include runtime errors as well.

I'm talking about unchecked exceptions. It's not about what is possible it's about what patterns a language encourages. It feels like we've lost the thread of discussion.

  - You say there is no difference between unchecked exceptions and Go's errors
  - I say yes there is since Go forces users to handle errors explicitly
  - You say that's not technically true in all cases.

OK. Yes. I should have said "nudges users" instead of force. It's a shortcoming of the language. It is still really hard for me to see unchecked exceptions and value-based error handling as the same thing. One of them encourages doing nothing and hoping that bubbling up is the right answer. Very often, especially in a multi-threaded context, it is not.

> You say there is no difference between unchecked exceptions and Go's errors

Where do I say that? I say that Go programmers, in 99.9% of cases, do manually what exceptions do automatically. In terms of cumbersome, error values are the equivalent of checked exceptions. The equivalent of runtime exceptions are panics.

Maybe I misinterpreted you. I don't disagree that checked exceptions and errors are ~the same thing.

> Go programmers, in 99.9% of cases, do manually what exceptions do automatically

Our experience working with Go must be very different.

Grepping for "err := " and looking at the first 10 results in my team's codebase.

  * 4 cases where the error is just returned
  * 1 case where the error is returned only if it matches a certain type (otherwise logged)
  * 1 case where the error is logged as a warning.
  * 1 case where the error is logged, some metric is incremented, and then execution continues as usual. (a fail-open authentication check)
  * 1 case where the error is returned as different error type.
  * 1 case where the error is returned, but only after accessing the result (this is a strange design / antipattern), and annotating it with a human-readable explanation.
  * 1 case where the error is treated as a boolean condition, and is not returned. (the error condition is "does not exist").

So in this sample it matches the "automatic behavior" in only about half the cases. In other cases, substituting the existing behavior with exception's automatic behavior would cause severe bugs.

This actually argues my point, because it seems (ignoring the strange design) only the last case would really exist in business code in another language.

(Obviously, without source code access the following is guesswork) The other cases might either not be required (since you'll get a stacktrace anyway and don't need to leave breadcrumbs) or be part of some general infrastructure, say interceptor, that logs interesting things on boundaries. At least that's my day to day experience comparing Go and Java.

There is a lot of confirmation bias in this post. I will leave it at that.

Nevertheless, thanks for trying to back it up with data. I'll use your method and look at our code when time allows it, to see if I need to adjust my priors.

> In Go the programmer is forced to make a decision on what to do with the error.

Actually go runs perfectly fine if you just do nothing with the error, and then you are flying past errors like it is nobody's business. Of course you can you static analysis to tell you if you forgot to handle an error, and most people do, but that is not really a language feature.

In Java a programmer is also forced to make a decision to add explicit exception handling or not. But if they choose to not add it, the program won't just pretend like all is fine and dandy, it will stop the execution of the current function and pass the exception up the stack.

The difference is that the error states are explicit rather than implicit. The function's signature tells you what the possible errors you'll need to handle are, so you don't get caught off guard at runtime.

As for stack traces: checked exceptions are semantically almost identical to error-as-value but they do give you a stack trace. They give you all the static guarantees of error-as-value plus the benefit of being able to know where the error came from.

> checked exceptions are semantically almost identical to error-as-value but they do give you a stack trace

I completely agree with you on that one. The only thing I'd want to add is that aside from example code, usually you don't care a lot about what specific errors might pop up, unless you're at the top level of your program. This might be the request handler, or some UI loop. On the other hand, where you care about errors, you usually don't care about results or their types.

I've been in the industry long enough that I vividly remember the catch-and-wrap orgies in Javaland of 2003. A lot of it was caused by the inferior type system of Java, which hinders composability (such as when a layer is moved to another node and suddendly you have to deal with remoting exceptions). But it also goes to show that knowing a specific class of error is often overrated in application code, and should be, well, the exception.

Catching unchecked exceptions at module boundaries is perfectly fine and as far as I know (which admittedly isn't much) both Go and Rust in fact allow doing exactly that.

Java got wrong with the concept of checked exceptions. They're not needed. Python, C++ or JavaScript exceptions are totally fine. And checked exceptions bring nothing but issues.

The only thing that I'd add to the unchecked exceptions is noexcept with compile-time checking. Something along the lines:

1. You can declare method as `nothrows`. Compiler will ensure that no exceptions are thrown (`java.lang.Error` can still be thrown, but you're not supposed to deal with it in any way in most code).

2. You can declare method as `throws Exception1, Exception2`. Compiler will ensure that only subclasses of those exceptions are thrown from this method.

3. You can omit any declaration. In this case compiler will compute list of possible exceptions implicitly (it's a union of all exceptions thrown by all called methods).

So basically it'll allow to: document list of thrown exceptions and it'll allow to statically check that other exceptions are not thrown, so this documentation is compiler-checked.

Of course this idea needs battle testing, but I think that I'd like it. You can either opt-in and write code documenting all thrown exceptions (which is good for libraries) or you can opt-out and write simple code without bothering with exceptions (which is good for applications).

Also there should be proper support for generic exceptions, so I can write Function<T, R, E> and E would be of type containing union of all thrown exceptions. That's required for example for moving exception signatures from lambdas in functional collections.

Java always gets the blame, yet the concept of checked exceptions was introduced by CLU, adopted by Modula-3 and C++, before it came to Java.

And even though C++ dropped exception specifications, they still kept the difference between might throw anything or doesn't throw at all, and there is also the paper to reintroduce them Swift style.

Those are not industry languages and Java was known to borrow only well developed and widely adopted features. For example it took like 20 years to add lambdas which were in lisp 60 years ago. Checked exceptions are a sore exception to this rule.

C++ isn't an industry language?!?

There're no checked exceptions in C++. noexcept does not do anything related to type system, it just terminates an application if an exception has been thrown.

CFront until C++11, and Herb's paper for value type exceptions...

I disagree that standard exceptions are fine for recoverable errors.

Recoverable error states are part of your function's interface. Languages with exceptions make this implicit: in order to know how to interface with a function's error states you have to go digging through the docs, which hopefully document the exceptions it throws. If they don't, then you either have to trace the entire call tree or just wait for the library to throw something so you know what you're supposed to be catching.

On the other hand, if a language requires that recoverable errors be documented in the function signature (either as a checked exception or error-as-value), you know that you're either handling the exceptions or intentionally letting them propagate. There are no surprises at runtime because the set of all possible error states is known statically.

The fact is that checked exceptions are avoided in modern Java. They are part of function interface, compiler forces you to handle or propagate it. Yet people didn't like it and actively sabotage this design. So this design didn't work. You can shove it down the peoples throat or you can design features that will help rather than irritate.

I long wished there was C# Intellisense that showed what kind of exceptions I may receive when calling particular function. At least from code it can infer from:

- .NET library has documentation comments, with <exception> tags

- It could look at my code and see what exceptions get thrown.

- It could be clever enough to know that new might throw OutOfMemoryException

- Clever enough to know checked arithmetic might throw OverflowException

- Might understand where/what exceptions get caught and do not bubble up.

- Smart enough to understand if value can possibly be null and properties are accessed, thus may result in ArgumentNullException.

- As for 3rd party code, I don't know if .pdb provide enough info to know whether particular function call may throw particular exception? But it's all IL, so that should be enough to infer from 3rd party code what kind of exceptions I might encounter:

   // throw new ArgumentNullException("serviceProvider");
   IL_0013: ldstr "serviceProvider"
   IL_0018: newobj instance void [mscorlib]System.ArgumentNullException::.ctor(string)
   IL_001d: throw

Eh, what a dream.

What you are asking for is checked exceptions where the caller gets notified by the compiler that the function you call might throw one or more exceptions.

However, it is worth taking it a step further and focus on "why the error occurred" instead of "an error has occurred".

An example of this is Code Contracts. Like Intellisense, live code analysis with contracts would tell you "the method you call will throw <exception-type> with the input you give".

Not only will that cover giving the user information about which error conditions that can arise, it will also give you the reason why.

Well, code contracts are unfortunately dead, not available in .NET Core.

C# Anders Hejlsberg, C# designer has a word on checked exceptions for which I agree with him that we should somehow address it more efficiently: https://www.artima.com/articles/the-trouble-with-checked-exc...

Looks like what I'd like in the meantime is soft-checked-exceptions. Well, just for documentation purposes. And I'll leave the code for myself. I just want to take into consideration various failure modes and now I can just do generic error handling or waste too much time. Yes, what you are saying, live code analysis would be good enough not to screw up C# language itself with bad design decisions.

> Exceptions are starting to feel like a legacy programming paradigm to me. Rust & Go have, at least in a practical programming context, shown that errors-as-values has far less footguns

They don't really. Because they force you to handle errors even in code that couldn't care less about errors because that's the responsibility of a higher level up the stack. And worse, they assume that an exception is a valid reason to just stop program execution altogether (when it rarely is).

See Erlang for how you should handle exceptions (you have a supervision tree with various restart strategies).

Just remembered that Rust realised that manual handling of errors everywhere doesn't work, and introduced `try!` macro, and then the `?` operator.

These are more practical (and good thing Rust isn't rigid at the expense of pragmatism).

And of course since panics are not the answer to everything exceptional, there's now a `catch_unwind`, too

Has it shown this? Are there solid metrics or is it simply because they're popular and it's not the idiomatic way to do things? My understanding is they still have panics anyhow.

I should have caveated that it's purely subjective. In my experience, developers write much more reliable and understandable code when they handle errors as values rather than as exceptions.

On the other hand the Rust syntax have gradually moved closer to exceptions, now with the "?" operator which automatically unpack the result or propagates the error value. This feels awfully close to exceptions, even if it in theory is "just a value".

I think the main difference is that it forces the acknowledgement of the error at the point of the function call, which is not the case with exceptions.

Not so much legacy as specifically of the time period where Java was created.

C++ doesn't do this (in the standard library, setting a good tone for idiomatic code).

Older languages don't abuse the exception idea. Nor do newer ones.

(Go is a bad example though, since it took the convenience of Java style exceptions away, but replaced them with nothing)

The Rust Result type combined with mandatory error handling leads to very robust programs. It is also easier to reason about, as there is no hidden (non-local) control flow. Exceptions are unergonomical and slow.

> feel anxious about calling a function and having absolutely no idea if or what exceptions it might throw

You can try doing what most of my coworkers do and just not care.

Exceptions work well for 2 kinds of error handling: crash and log, and general retry and log.

The second one is more cumbersome with return values if the possible errors originate deep in the stack.

Beyond a simple retry, Exceptions are not specific enough for handling errors.

Exceptions are typically custom types - you can build an arbitrarily detailed exception taxonomy (typically branching off the language-standard one), and in most (all?) languages supporting exceptions, you can also give them arbitrary state.

You really can't get more specific than that. If exceptions still feel "not specific enough for handling errors", perhaps it's because you're only thinking of most trivial examples, as given by 101 tutorials and people arguing against exception handling?

You can build a separate exception for every possible raise site. But that is overly burdensome. Moreover, there is no guarantee that any (standard) library calls have an appropriately detailed taxonomy. You could, of course, wrap these library calls and catch exceptions so you can re-raise them yourself. But at that point you are losing the main advantage of exceptions over return values: the ability to separate the happy path from the error-handling path.

To me, once I am building my own expansive taxonomy of exceptions, I am much happier using Optional, or Result/Either type return values.

> You can build a separate exception for every possible raise site.

Why would you want to do that? You don't do that with Result/Either.

> To me, once I am building my own expansive taxonomy of exceptions, I am much happier using Optional, or Result/Either type return values.

I may be missing something, because to me, this doesn't follow. Optional type is "result or nothing"; and with Result/Either type, you either use something generic (e.g. symbol, string), or go very specific (even if it's just one of the dozen different "newtype" names for symbol/string). To me, this choice with Result/Either is exactly equivalent to choosing an exception taxonomy. You're doing the same work either way.

With result/either you are forced to handle the error very close to where it happend. With exceptions (in my understanding) the goal is to be able to handle errors much further up the stack. But in such cases you aren't sure where the exception originated, so you need to encode that in the exception to understand the error.

If you do very close exception handling, you lose what I consider to be 'the point of exceptions'. Hence I don't think that should be done.

The core of my argument is then that error handling beyond 'just retry' needs a lot of detail about the error. And I believe this detail is easier to encode if the error handling is close to the error. Since exception handling is meant to be further away from the error, it isn't as suited to this kind of error handling.

Rust do still has exceptions, they're just called "results". You can't really have values as exceptions unless you plug a lot of ad-hoc constructs into your language so that they eventually become similar to exceptions [1]:

> Add syntactic sugar for working with the Result type which models common exception handling constructs.

The whole error handling story with Rust can be summarized as "we have results but want to have exceptions".

[1] https://rust-lang.github.io/rfcs/0243-trait-based-exception-...

Errors in rust are not exceptions, they're data contained within an `Either` monad (Result)

Additionally, on top of the linked RFC being nearly 9 years old it doesn't at all indicate "we want to have exceptions".

The ? operator allows propogating the errors if they can't be immediately handled (similar to monadic `do` notation, or early returns)

Just because Rust people are in denial about it doesn't make them not exceptions. The Either/Result monad is isomorphic to checked exceptions, with any differences being pretty much just syntax.

It makes generics and higher-order functions much more elegant. Any function of `(a->t)->t`(or many other similar signatures) will automatically be able to return the correct error type if t is a Result<>.

Compare this to checked exceptions, where (even in an ideal world) you'd need a separate type parameter for the error type, plus a bunch of extra language features and syntax to make it work. And then what happens if you want to use the same function with _no_ error type?

For a concrete example, try using Java's `stream().map()` with checked exceptions.

Of course there are implementations of checked exceptions which are much closer to Result than Java's implementation, and in those cases I would agree with you.

No! Exceptions have a very well defined meaning. Exceptions in Rust are non-aborting panics.

When people talk about "exceptions", they mean resumable exceptions that are intended to be caught. But "catching" an unwinding panic in Rust is so (deliberately!) limited, cumbersome, and unidiomatic that it doesn't qualify as an implementation of resumable exceptions. The only reason the ability to "catch" an unwinding panic even exists in Rust is to prevent unwinding across FFI boundaries, which would be UB; it's a correctness mechanism, not an error-handling mechanism.

Reply on news.ycombinator.com