Type-safe and user-friendly error handling in Swift 6

They also failed because Java never made them easy to work with. If you faced a checked error that you couldn't handle it is impractical to uncheck them. You have to write a shit ton of boilerplate.

    A a;
    try {
        a = someThrowingFn();
    } catch (AException ex) {
        throw new RuntimeException(ex);
    }

It sucks. In Swift this is simply: val a = try! someThrowingFn(); Kotlin is moving towards having both unchecked exceptions (panics) and errors as values. I think its absolutely the correct decision. They're also including an easy way to panic when you can't handle an error: val a = someThrowingFn()!!;

The other thing that I think made checked exceptions worse in the beginning was the lack of pattern matching and sealing with exceptions. Being able to exhaust all the different types of a particular error is really important if you want to properly respond. If you had a meaningless top level exception like IOException you couldn't effectively determine what actually happened and everyone just defaulted to unchecking it. Nowadays it's a little better if you seal your exception hierarchy:

    sealed abstract class SomeException extends Exception permits A, B {
        final class B extends SomeException {}
        final class C extends SomeException {}
    }
    
    try {
        someThrowingFn();
    } catch (SomeException ex) {
        switch (ex) {
           case A a -> iCanHandleA(a);
           case B b -> throw new IllegalStateException(b); // can't handle this one
        }
    }

Hopefully that becomes even better with the exceptions in switch [1] proposal:

    switch (someThrowingFn()) {
        case throws A a -> ..
        case throws B b -> ..
    }

The real big issue like you said is that they're not completely in the type system. Especially when it comes to lambdas; you need to invent a Result<T, E> type every time you want to work with lambdas. Obviously all of these things are solvable with library code, try! is easily some static panic function; it sure would be nice to not have to write them. Overall I'm hopeful that with the overall programming community moving back towards checked errors that the OpenJdk team will invest in making checked exceptions better, but only time will tell.

[0] github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md [1] https://openjdk.org/jeps/8323658

Yet I regularly miss them when coding in C# and Typescript.

I also used the C++ exception specifiers, which people keep forgetting is where Java's idea came from, alongside other languages like Modula-3.

That's actually the same as Java, with its "checked exceptions" (aka listed in function signatures), and the RunTimeException hierachy which don't have to be listed.

In Java common errors and exceptions, like file I/O errors, have to be declared on each function signature, except everything under the RunTimeException hierachy is exempt from this requirment. In the language, RunTimeExceptions these are the messy errors like NullPointerException and ArithmeticException.

In practice, people do subclass program-specific exceptions under RunTimeException in Java, as well as wrapping existing exceptions inside a RunTimeException, for the sole purpose of not having to add them to function signatures all over the place.

It’s typed throws specifically.

Before Swift 6 a function either could throw nothing or could throw anything, like Java’s “throws Exception”.

Now you can mark that a function can only throw a specific error type but nothing else, like Java’s “throws MyCustomException”.

Seems you can’t list multiple types. You’d have to have them in a class hierarchy and mark the base type.

What I like about this idea: if a function is marked like this, Swift can tell that a catch block is exhaustive without needing a “catch all” error case. And if the function starts throwing more possibilities than you coded for, e.g. new case added to an enum, you get a compiler error! Not a submarine bug.

    enum FooError: Error {
        case myError(MyError)
        case badError(BadError)
        case thirdError(ThirdError)
    }

The new feature here is typed throws, which I referred to as statically typed errors. You’ve always been able to throw a subtype of Error and then dynamically downcast it at runtime, but function signatures were limited to “throws any subtype of Error” or “doesn’t throw at all.”

Sealed classes fall into the realm of things that the Swift language designers would leave up to convention. For example, using underscored public methods for internal methods that need to have external linkage, rather than inventing a new keyword for this purpose.

Why would sealed classes be bad design? It helps the compiler and you ensure that you have correct code and have handled all cases.

Oh I see, the original article didn’t use this syntax.