Shorthand for exhaustive catch statements


(Simon Pilkington) #1

As a number of recent threads have shown, typed throws and error handling is a complicated topic with a lot of implications.

However in the mean time we could potentially address one of the pain points people give for wanting typed throws - exhaustive catch statements.

For functions that you completely control, it is possible to be completely certain of the errors the function will throw and it is an unrecoverable logical error for any other error to be thrown. Currently this situation would have to be handled like so-

do {
    try throwingFunction()
} catch MyError.TheError(let theContext) {
    // do something
} catch {
    fatalError(“Impossible error?")
}

Here, the catch-all is just boilerplate to make the catch statement exhaustive but doesn’t provide any value to the programmer. Would it make sense to provide a shorthand for this case like this-

do {
    try! throwingFunction()
} catch MyError.TheError(let theContext) {
    // do something
}

Where the try! still indicates the call could fatalError if the function throws an unmatched error but allows the programmer to specify the errors that they specifically want to handle. I don’t think this moves the language away from the possibility of typed throws; adding typed throws would likely cause a warning in both cases - either to remove the catch-all or all the ! - if the compiler could determine the catch was now exhaustive without them.

If this has been proposed elsewhere I apologise.

Cheers,
Simon


(Xiaodi Wu) #2

_If_ this is something that's important, then the ! should follow 'catch'
and not 'try'.

The keyword 'try!' already means something, and it's not that. People may
already mix try! and try in a do block and the behavior cannot be changed
for source compatibility.

···

On Sat, May 6, 2017 at 15:16 Simon Pilkington via swift-evolution < swift-evolution@swift.org> wrote:

As a number of recent threads have shown, typed throws and error handling
is a complicated topic with a lot of implications.

However in the mean time we could potentially address one of the pain
points people give for wanting typed throws - exhaustive catch statements.

For functions that you completely control, it is possible to be completely
certain of the errors the function will throw and it is an unrecoverable
logical error for any other error to be thrown. Currently this situation
would have to be handled like so-

do {
    try throwingFunction()
} catch MyError.TheError(let theContext) {
    // do something
} catch {
    fatalError(“Impossible error?")
}

Here, the catch-all is just boilerplate to make the catch statement
exhaustive but doesn’t provide any value to the programmer. Would it make
sense to provide a shorthand for this case like this-

do {
    try! throwingFunction()
} catch MyError.TheError(let theContext) {
    // do something
}

Where the try! still indicates the call could fatalError if the function
throws an unmatched error but allows the programmer to specify the errors
that they specifically want to handle. I don’t think this moves the
language away from the possibility of typed throws; adding typed throws
would likely cause a warning in both cases - either to remove the catch-all
or all the ! - if the compiler could determine the catch was now exhaustive
without them.

If this has been proposed elsewhere I apologise.

Cheers,
Simon
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Simon Pilkington) #3

I actually half agree with you that this behaviour would be conceptually related to the do-catch block (although not a specific catch statement). So maybe alternatively the shorthand for this-

    do {
        try throwingFunction()
    } catch MyError.TheError {
        // do something
    } catch {
       fatalError("Expected error?")
    }

could be instead-

    do! {
        try throwingFunction()
    } catch MyError.TheError {
        // do something
    }

This would also avoid any conflict with existing behaviour.

Cheers,
Simon

···

On 6 May 2017, at 1:26 pm, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

_If_ this is something that's important, then the ! should follow 'catch' and not 'try'.

The keyword 'try!' already means something, and it's not that. People may already mix try! and try in a do block and the behavior cannot be changed for source compatibility.
On Sat, May 6, 2017 at 15:16 Simon Pilkington via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
As a number of recent threads have shown, typed throws and error handling is a complicated topic with a lot of implications.

However in the mean time we could potentially address one of the pain points people give for wanting typed throws - exhaustive catch statements.

For functions that you completely control, it is possible to be completely certain of the errors the function will throw and it is an unrecoverable logical error for any other error to be thrown. Currently this situation would have to be handled like so-

do {
    try throwingFunction()
} catch MyError.TheError(let theContext) {
    // do something
} catch {
    fatalError(“Impossible error?")
}

Here, the catch-all is just boilerplate to make the catch statement exhaustive but doesn’t provide any value to the programmer. Would it make sense to provide a shorthand for this case like this-

do {
    try! throwingFunction()
} catch MyError.TheError(let theContext) {
    // do something
}

Where the try! still indicates the call could fatalError if the function throws an unmatched error but allows the programmer to specify the errors that they specifically want to handle. I don’t think this moves the language away from the possibility of typed throws; adding typed throws would likely cause a warning in both cases - either to remove the catch-all or all the ! - if the compiler could determine the catch was now exhaustive without them.

If this has been proposed elsewhere I apologise.

Cheers,
Simon
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution