Hacker News Reader

Comment by lifthrasiir | Hacker News Reader

People say they hate exceptions much, but what they actually hate is either one of two subsets of exceptions: Java-esque checked exceptions and C++-style untyped (and heavy) exceptions. Result type is an implementation of much wanted middle ground: explicitly typed but ergonomic enough exceptions. Its non-abrupt nature is, in my opinion, just a side effect.

By comparison exceptions, as a means to abruptly terminate the thread of computation, is not something you can simply replace (unless you do total programming). Most languages with result types do have exceptions in this sense: ML `raise`, Haskell `error`, Rust `panic!` etc. Passerine seems not much different. (Note: the whole error system is, as far as I see, completely unimplemented.)

View on HN

Hey, author of this language here. I love Rust, but what I like the least about `panic!` is the lack of context it provides. I mean, sure, there's `RUST_TRACEBACK=1`, but that's not nearly as neat as a real traceback, with the appropriate context and data to help determine the root of the problem.

I'm still thinking through my design options, because I've been recently reading a lot about Algebraic Effects. I'd hate to have two non-orthogonal features in a minimal language, which is why I'm waiting until more of the language has solidified and I've reached a conclusion about Algeffs before implementing the whole error system.

Thanks!

Yeah, exceptions are not enough for fully reconstructing the problem! I'm not sure this can and should be necessarily fixed by changing exceptions, though. It is often the case that you need a deep trace to understand the problem and mainstream tooling is not prepared for that (I wish rr to be more widespread).

For algebraic effects: I too had keen eyes to Koka and think that it might be the future. What I don't know is how to make effect types mostly invisible to users without sacrificing its power. I had been experimenting with dynamic scoping in my mind, but that feels unsatisfactory.

Resumable exceptions - ie, exceptions that don't unwind the stack when they are thrown - do let you examine the problem in situ.

I left this comment just a couple of days ago - I don't see any reasonable solution for this except (ha) exceptions:

https://news.ycombinator.com/item?id=26198607

i remembering seeing and appreciating this one a few days ago :)

Oh cool! Happy to hear :)

Technically speaking cancellable sort requires non-local jumps, which includes exceptions but also many others (call/cc, delimited continuations, algebraic effects, ...). It can be also argued that the general idea of cancellation is an exception (as in futures). In any case we are not dealing with something unnecessarily requiring exceptions.

> which includes exceptions but also many others (call/cc, delimited continuations, algebraic effects, ...)

I think you might be missing my point? How would you use call/cc or the rest with arbitrary callers? Do you write everything in that manner all the time? Do you realistically expect others to?

> How would you use call/cc or the rest with arbitrary callers?

For example, with shift/reset operators (a form of delimited continuations) you can do something like this pseudo-JS code:

    const cancelled = reset {
        arr.sort((a, b) => {
            if (aborted()) {
                shift (k) {
                    // k is a continuation from shift to reset,
                    // but we want early return so we discard k
                    // and replace the reset expr with false.
                    return false;
                }
            }
            return compareTo(a, b);
        });
        // this will replace the reset expr if shift is not triggered.
        return true;
    };

Every example I've mentioned can be used to implement exceptions after all, so if you know something can be done with exceptions, you can do the same with call/cc and so on as well.

This is basically a functional version of setjmp and longjmp right? Meaning it has the same problems? How do you ensure the caller's cleanups etc. still occur so you don't mess up the program state?

I'm not sure about "messing up the program state". Do you mean the memory error like segfault, or the `finally` block? My answer would depend on the answer:

Memory error: Instead of the register states for setjmp, call/cc and so on give you a well-behaved function of the continuation. I will spare what the continuation is but basically it's possible to convert any code into a code with the explicit continuation available as a function at any time (Continuation-Passing Style). So unlike setjmp/longjmp you can be sure that everything will be a normal function call in the end. (The actual implementation can of course vary.)

`finally` block: You are kinda right. They are used to implement things like more readable control structures like exceptions and cumbersome to use directly. There are things like `dynamic-wind` in the Scheme world, but it's true that if you weren't aware you can easily screw up. My point stands though, what you need is a non-local jump and not the exception proper. It just happens that the most widespread non-local jump construct is an exception.

I meant finally blocks... freeing memory, reverting changes, etc... which are things you'd use destructors for (and hence why you can't use setjmp/longjmp with them). If you don't do them then you mess up your program's state and hence have no way to ensure correct behavior afterward. This is why I mentioned arbitrary callers: you have no idea what callers have done or what they still need to do before returning. Heck, even sort() could have allocated memory that you'd be leaking, and not all destructors are constrained to resource leaks either.

I don't know what you consider "exceptions proper" (do you have to inherit from Exception? do you even have to pass along extra information?) but I don't think I agree. My point is actually precisely that what you want is not a non-local jump, but actual unwinding. Semantically, this is what exceptions are: synchronous dynamic unwinding. If you have a way to stop control flow and unwind arbitrary callers in a synchronous manner, what you have is exceptions, regardless of the particular syntax or other details. (e.g., it's beside my point you can "throw" extra information alongside this mechanism, or whether it's part of the language or a library, or whether you do the unwinding on the heap vs. the stack, or whether it's functional or procedural, or what have you.)

And my overall point is that this kind of dynamic unwinding is necessary for you to be able to do certain things like canceling routines in the middle in a safe and well-defined manner. (Especially that Result<>/Optional<>/whatever explicit localized mechanism is in fashion these days is clearly an insufficient replacement for exceptions.)

I'm in principle in agreement. You do need unwinding. Specifically I meant an explicitly triggered unwinding by "exceptions proper". I just wanted to point out that unwinding is much broader than exceptions. (For example generators will implicitly unwind upon its cleanup. Of course it requires callee's cooperation and I couldn't use it as an example.) I also don't buy the claim that explicit Result types are incompatible with unwinding---e.g. RAII works fine with result types.

Languages that do Result + panic, or languages that do checked + unchecked exceptions. Which is best?

IMO, I think "Result + panic" works better because it's a cleaner separation in the sense that handling panics is strongly discouraged. Whereas handling unchecked exceptions happens all the time, and leads to confusion.

Edit: To clarify, I would consider Go to be "Result + panic" even though it doesn't have a Result interface. It has a convention of returning a tuple of "value, err", which is handled by the caller and is essentially an informal Result.

"Panic" is a fancy name for unchecked exception. It can arise from any code, for example, by out-of-index accesses or arithmetic overflows. In the other words, if you want to allow, say, `arr[0]` without any checking, you should accept that it can abruptly terminate the current thread. (Pony is a rare example of the contrapositive.) I too agree that "Result + panic" is better for the very same reason, but it doesn't mean exceptions are gone.

Handling unchecked exceptions "happens all the time" because in certain languages and libraries, like Java, it looks like less work than tediously checking error conditions or letting the program die properly. Different kinds of software in a different language can fare very differently.

Reply on news.ycombinator.com