Hacker News Reader

So how do you want to handle something like sqrt(-1.0) for real numbers? A runtime exception seems the sane way to do it for me. Are you suggesting that sqrt(-1.0) or any other invalid value should return a sentinel value like -999, or should return NUL instead of a real?

Any way of dealing with errors has to be out of band, we just disagree on the mechanism.

sqrt(-1.0) is NaN, it's typically used in numerical code where you can't stop and check for exceptions because performance is key.

But just for the sake of argument, the type of 'sqrt' isn't:

    sqrt : R -> R

it is:

    sqrt : R+ -> R+

So you have two options here. You can have sqrt return "Either Error Double" and force the programmer to deal with the possibility of an error (Rust does this) or you define a "nonnegative real" type that the compiler can guarantee will be an acceptable input for sqrt. The latter is much harder to do.

But either way no, you only need an "out of band" mechanism when the type system isn't strong enough or isn't being properly leveraged.

I used square root because it is commonly known that negative numbers are a problem for them. What about tangent(x) which periodically blows up? A type system can't fix that.

In my opinion it is far better to throw an exception that can be explicitly handled, rather than cause some math error at some random point later because NaN or some infinity snuck by as a number.

Math.tan will never throw exceptions because, for the exact same reason as above, it won't check its input.

But again for the sake of argument, the return type of tan() could be "Either<Error, double>".

I guess I would get used to that, but it seems broken to me. The way to deal with that is out of band, checking for the type to change to "Error"

In Pascal tan(pi/2) or tan(3pi/2) causes an overflow. The way to deal with that is out of band, to handle an exception of type E_Overflow.

Again no, it isn't. You are well entitled to believe Pascal is the best thing since sliced bread, but the two ideas are fundamentally different.

There is no type change. The function "tan" would return a value of type "Either<Error, double>". An expression such as:

   double x = Math.tan(Math.PI / 8)

would fail the compile-time type check, because the type of the variable "x" is "double" and the type of the expression "Math.tan(Math.PI / 8)" is "Either<Error, double>".

It would be the responsibility of the caller to prove to the type system that the error has been handled, with either a built-in language facility a la ML, or with ad-hoc code such as a Bohm-Berarducci construction.

Let's just agree to disagree.

I know Pascal isn't perfect, and lots has been learned since then... this is genuine confusion on my part. So tan in your system returns a variant type (could be Error, could be Double), right? (I didn't get that)

Compilers can find all sorts of things they couldn't in the past, which is amazing.

What happens at run-time if an overflow happens?

again... I'm sorry if I didn't express myself clearly enough. I'm coming at this from a Pascal programmers perspective... I've missed the past 20 years of compiler improvements.

Rust chooses to panic, I believe, but you could always have applied the same Error strategy — it’d just be really annoying. The stdlib also provides a bunch of methods to pick-your-strategy for overflow behavior, but you need to use them instead of the +/* operation

In Rust in particular (and many other languages) tan operates on IEEE 754 double-precision floating points ("double" for Free Pascal, "f64" for Rust). These can contain infinity and NAN values, not just numbers. So if tan blows up, you get NAN back. It's your job as the programmer to check that the result wasn't NAN (or INF) before proceeding. "Double" is already such a variant type. So you have to check your results which can return an error variant for errors, just like you already do with floating-point values.

Like you said, this is a variant type that represents either a value, or an error. Here's the definition of Rust's Result type:

  pub enum Result<T, E> {
      Ok(T),
      Err(E),
  }

I threw together some examples of how you can use a Result value, although I used arcsin instead of tan as the out-of-domain values are much easier to specify.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

I'm not entirely sure what you're asking about regarding runtime behaviour, but here's two guesses.

As a user of a function that returns a Result type, at runtime the function returns a result that has a flag and a payload, where the flag specifies whether the payload is your value or an error. The only ways to get a value out of the result are either to check the flag and handle both possibilities, or to check it and crash the program if it's an error.

As someone writing a function that returns a result type, you write whatever logic you need to determine whether you've successfully produced a value, or which error you've produced, and then you either return(Ok(my_value)); or return(Err(my_error));. If you're doing floating point math, this might be checking an overflow flag, or looking at your inputs, or checking for NaN after operating, or whatever makes sense for your task.

Using a variant/product/discriminated union like this is orthogonal to the details of floating point operations at runtime. What it lets you do is have the compiler enforce that users of your function must check for errors, as it's a type error to assign a Result<f64,E> to a variable of type f64.

I hope that helps! Do you have any more questions about this, or things I didn't address, or topics where you'd like more explanation or examples?

Sqrt(-1.0) should return NaN or raise a signal. Let the programmer choose. Throwing an exception doesn’t help anyone.

There have been many studies of exception handling correctness. They’ve shown that no one can correctly write exception handlers.

In my experience, proper exception handling is more difficult than advanced topics like lock free data structures, with the disadvantage that junior programmers have been taught to use exceptions and avoid lock free primitives.

> If a function can fail I want to see it right there on the return type and be forced to handle it on the spot.

Checked exceptions solve this problem. Checked exceptions vs. result sum types aren’t a black and white dichotomy, however. They are rather two points on a design spectrum, where one design axis is how you want to syntactically handle error escalation up the call chain, another axis is how you want to handle destructuring/restructuring of the results, etc.

Unchecked exceptions are still useful for notifying bugs (e.g. precondition violations) instead of aborting the OS process on failed assertions.

> Exceptions are an invisible, out-of-band mechanism that will crash your program because you forgot yet another try...catch.

Out-of-band is the point. It lets you write your code for the correct path, without having to explicitly string a bunch of error types along (or do something annoying like mandating all errors are of type Error, which is a string).

The problem is with invisibility, which is the case with most exception-using languages. Java had it solved right, though, with checked exceptions. Of course back in the 2000s we were a bunch of lazy children and said "checked exceptions are bad because they make us declare stuff up front", which was actually a good thing, but we couldn't understand that, so they became optional in Java.

(On the other hand, exception handling is just a poor shard of proper condition system, like in Common Lisp.)

If you squint hard enough checked exceptions are sum types through other means:

  try
    foo()
  catch ExceptionX
    ...handle X...
  catch ExceptionY
    ...handle Y...
  catch ExceptionZ
    ...handle Z...

compare that to (borrowing some Rust-ish syntax):

  match foo() {
    ExceptionX => ...handle X...
    ExceptionY => ...handle Y...
    ExceptionZ => ...handle Z...
  }

with the added benefits that sum types can be used outside of error handling.

Yep, they are essentially sum types, but out-of-band, which is important.

In particular, you can have:

  def quux():
    xkcd = frob(foo(), zomg())
    ...lots of code...

  def bar():
    try
      quux()
    catch ExceptionX
      ...handle X...

  def baz():
    try
      bar()
    catch ExceptionY
      ...handle Y...

I assume pattern-matching can be partial without explicit default value, but (in the languages I've dealt with) it gets tricky with expressions. For instance, in C++:

  auto a = foo();
  auto b = bar(a, quux());
  return frob(xkcd(a), b);

if foo(), bar() and quux() can throw exceptions, and you wanted to replace them with sum types - say, std::variant<F, Err1, Err2, Err3>, or for better semantic separation (more on this below), tl::expected<F, std::variant<Err1, Err2, Err3>> - you'll going to pray you have enough "monadic" methods in those classes (spoiler alert: you don't, as of C++17/current tl::expected) to rescue the spaghetti code you'll have to write to model this flow.

Recently, I've been dealing with a C++ codebase that uses tl::expected in lieu of exceptions, and while the "main flow" becomes more readable - return doThis(x, y).and_then(do_that).map(sth).map_error(logErrors); - the side effect is that the codebase is littered with trivial functions and closures to make that interface work. It's much less readable than a bunch of catch blocks every now and then. Maybe it's a limitation of C++? I feel like a syntax for partial application would remove half of the boilerplate I have to write when chaining tl::expected-returning functions.

On semantic separation, I alluded to using a "nested" sum type like (Result1 + Result2 + ...) + (Err1 + Err2 + ...) instead of Result1 + Result2 + ... + Err1 + Err2 + ... - while mathematically equivalent, they aren't syntactically equivalent in code. Grouping possible return value types separately from possible error type values improves reasoning about code - the groups tend to change independently from function to function. And if you squint, this is what exceptions give you: they separate the error sum type from return sum type, and give the former a completely different control path. This means you can think about them separately, and don't have to force-fit the success path into shape that satisfies the needs of the error path.

Typed checked exceptions are a bad thing because they require libraries to redeclare things that are its implementation details, in particular the API of other libraries they use internally.

See Swift's error handling design: https://github.com/apple/swift/blob/main/docs/ErrorHandlingR...

(Also, exceptions/nonlocal returns are a pain because the invisible control flow is hard to reason about and hard to implement in a compiler.)

> they require libraries to redeclare things that are its implementation details

Exceptions that can fly out of a library are just as much a part of its public interface as the error types it uses for return values. Adding a checked exception Exception is equivalent to turning your Foo return value into Result<Foo> - the code will no longer work if it doesn't handle it.

> in particular the API of other libraries they use internally.

The library can make a choice between handling the internal exceptions at the interface boundary, rewrapping them, or exposing them as a part of its public interface. That's no different than a library considering returning a type that's defined in another library it uses internally.

> (Also, exceptions/nonlocal returns are a pain because the invisible control flow is hard to reason about and hard to implement in a compiler.)

I'm not a compiler guy so I'm not going to dispute the issues with implementing exceptions, but on the readability flow, I strongly disagree. There's nothing hard in exception-based control flow. The rule is simple: a given function either succeeds, returning what it declares, or fails - a failure cause the caller to enter the appropriate exception handling block if it has one, or exit immediately, propagating the exception up the stack.

I think the whole "exceptions vs. error types" debate is stupid, because both are designed for wildly different scenarios and as such are both non-optional.

An error type is for any deviation from the happy path that can be reasonably expected to occur during normal operation, and which my program must be able to handle. For a HTTP request, this would be something like "connection reset by peer" or "expected 200, got 404".

An exception is for any deviation from the happy path that a reasonable program cannot be expected to handle. For a HTTP request, this would be something like "malloc for send buffer failed".

Error types should be very visible in your function signature and their handling should be enforced or at least linted by the tooling, since failure to handle them very likely is a bug.

Exceptions, on the other hand, should be mostly invisible since most code cannot do anything when an exception occurs. In fact, if I had to design a language, I'd probably try to get by with reducing the try-catch-finally triad to try-finally or even just finally. Sometimes it's really useful to clean up after yourself before continuing to die, but if you can recover from an exception, you probably should have had an error value in the first place.

This difference is covered in Swift's design doc above, but its result is to technically not have exceptions (nonlocal returns), have fake exceptions called errors for "recoverable" errors (user can fix it), and just straight up crash for "universal" errors (vague things the user can't fix).