A unified error handling mechanism?

Evolution Discussion
1

Hi,

I do a lot of training and one of the features of Swift that seems more
confusing to students (and myself) is error handling. There are too many
ways of doing it, and none seems satisfactory.

Let's take for example an initializer. There are 2 different ways of
handling errors within an init:

a) Old School: return nil. This was very simple in Objective C, because the
uncommon case of an error could be easily ignored...until everything
crashed.

In Swift it's not easy (nor advisable IMHO) to completely ignore the
possibility of an error. Besides, it has 2 complications.

First of all, you return an Optional, and Optionals have a tendency to go
viral. Suddenly, all your code has to deal with optionals.

Secondly, you have no information about the error itself.

b) do/try/catch

This allows you to have information about the error, but also causes the
newly created object to be "trapped" inside a do block.

Are there any plans to address this situation? I believe there should be a
single, obvious and convenient way of handling errors in the language.

What do you guys think?

···

--

* <http://keepcoding.io/es/&gt;\*

*Fernando Rodríguez*

m. +34 610 965 332

t. +34 91 629 57 61

fernando@k <fernando@agbo.biz>eepcoding.io

[image: pastedGraphic.png] [image: pastedGraphic_1.png] [image:
pastedGraphic_2.png]

*KeepCoding.io*

2120 University Avenue, Berkeley, CA

Avda. Fuencarral, 44, Ed. 8, Loft 30

28108 Alcobendas (Madrid) Spain

2

do/try/catch use the error handling mechanism, named exception.

I think we should use it carefully , it will results convoluted code and
the risk of exception safe.

Fernando Rodríguez <swift-evolution@swift.org>于2016年8月6日 周六07:50写道：

···

Hi,

I do a lot of training and one of the features of Swift that seems more
confusing to students (and myself) is error handling. There are too many
ways of doing it, and none seems satisfactory.

Let's take for example an initializer. There are 2 different ways of
handling errors within an init:

a) Old School: return nil. This was very simple in Objective C, because
the uncommon case of an error could be easily ignored...until everything
crashed.

In Swift it's not easy (nor advisable IMHO) to completely ignore the
possibility of an error. Besides, it has 2 complications.

First of all, you return an Optional, and Optionals have a tendency to go
viral. Suddenly, all your code has to deal with optionals.

Secondly, you have no information about the error itself.

b) do/try/catch

This allows you to have information about the error, but also causes the
newly created object to be "trapped" inside a do block.

Are there any plans to address this situation? I believe there should be a
single, obvious and convenient way of handling errors in the language.

What do you guys think?

--

* <http://keepcoding.io/es/&gt;\*

*Fernando Rodríguez*

m. +34 610 965 332

t. +34 91 629 57 61

fernando@k <fernando@agbo.biz>eepcoding.io

[image: pastedGraphic.png] [image: pastedGraphic_1.png] [image:
pastedGraphic_2.png]

*KeepCoding.io*

2120 University Avenue, Berkeley, CA

Avda. Fuencarral, 44, Ed. 8, Loft 30

28108 Alcobendas (Madrid) Spain

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

3

Hi,

I do a lot of training and one of the features of Swift that seems more confusing to students (and myself) is error handling. There are too many ways of doing it, and none seems satisfactory.

Let's take for example an initializer. There are 2 different ways of handling errors within an init:

a) Old School: return nil. This was very simple in Objective C, because the uncommon case of an error could be easily ignored...until everything crashed.

In Swift it's not easy (nor advisable IMHO) to completely ignore the possibility of an error. Besides, it has 2 complications.

First of all, you return an Optional, and Optionals have a tendency to go viral. Suddenly, all your code has to deal with optionals.

Secondly, you have no information about the error itself.

b) do/try/catch

This allows you to have information about the error, but also causes the newly created object to be "trapped" inside a do block.

You can define an uninitialised variable outside the scope of `do`, and assign to it within the scope of `do`.

func test() throws -> Int { return 1 }

let variable: Int

do {
  variable = try test()
} catch let error {
  fatalError("\(error)")
}

print(variable)

···

On 6 Aug 2016, at 7:50 AM, Fernando Rodríguez via swift-evolution <swift-evolution@swift.org> wrote:

Are there any plans to address this situation? I believe there should be a single, obvious and convenient way of handling errors in the language.

What do you guys think?

--

<http://keepcoding.io/es/&gt;

Fernando Rodríguez
m. +34 610 965 332
t. +34 91 629 57 61
fernando@k <mailto:fernando@agbo.biz>eepcoding.io <http://eepcoding.io/&gt;
  
KeepCoding.io
2120 University Avenue, Berkeley, CA

Avda. Fuencarral, 44, Ed. 8, Loft 30
28108 Alcobendas (Madrid) Spain

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

4

Hi Fernando,

Some projects use a result type to unify the error handling. GitHub - antitypical/Result: Swift type modelling the success/failure of arbitrary operations.

There has been discussions about this and Chris L thinks that we may get a native (constrained) result type at some point.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007858.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008057.html

I can see a future where these get unified but the main issue imo is cocoa compatibility.

Probably swift 5+

Cheers!,
J. Cheyo

···

On Aug 5, 2016, at 4:50 PM, Fernando Rodríguez via swift-evolution <swift-evolution@swift.org> wrote:

Hi,

I do a lot of training and one of the features of Swift that seems more confusing to students (and myself) is error handling. There are too many ways of doing it, and none seems satisfactory.

Let's take for example an initializer. There are 2 different ways of handling errors within an init:

a) Old School: return nil. This was very simple in Objective C, because the uncommon case of an error could be easily ignored...until everything crashed.

In Swift it's not easy (nor advisable IMHO) to completely ignore the possibility of an error. Besides, it has 2 complications.

First of all, you return an Optional, and Optionals have a tendency to go viral. Suddenly, all your code has to deal with optionals.

Secondly, you have no information about the error itself.

b) do/try/catch

This allows you to have information about the error, but also causes the newly created object to be "trapped" inside a do block.

Are there any plans to address this situation? I believe there should be a single, obvious and convenient way of handling errors in the language.

What do you guys think?

--

<http://keepcoding.io/es/&gt;

Fernando Rodríguez
m. +34 610 965 332
t. +34 91 629 57 61
fernando@k <mailto:fernando@agbo.biz>eepcoding.io <http://eepcoding.io/&gt;
  
KeepCoding.io
2120 University Avenue, Berkeley, CA

Avda. Fuencarral, 44, Ed. 8, Loft 30
28108 Alcobendas (Madrid) Spain

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

5

b) do/try/catch

This allows you to have information about the error, but also causes the
newly created object to be "trapped" inside a do block.

Are there any plans to address this situation? I believe there should be a
single, obvious and convenient way of handling errors in the language.

func attempt<T>(_ expression: @autoclosure () throws -> T, handler:
(ErrorProtocol) -> T) -> T {
    do {
        return try expression()
    } catch {
        return handler(error)
    }
}
let x = attempt(downloadDataOrThrow()) {
    print("Connection lost")
    return nil
}

It mimics guard statement. You can also have versions of attempt with
partially defined handlers, like “return nil“ or “print and crash”, or
“assert type of error”.
​

···

2016-08-06 2:50 GMT+03:00 Fernando Rodríguez <swift-evolution@swift.org>:

6

Fernando, the rationale behind the design of error handling in Swift is
detailed here:
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst
Some of that document may now be out-of-date, but you may find it to be
helpful nonetheless.

···

On Sat, Aug 6, 2016 at 10:40 AM, Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

2016-08-06 2:50 GMT+03:00 Fernando Rodríguez <swift-evolution@swift.org>:

b) do/try/catch

This allows you to have information about the error, but also causes the
newly created object to be "trapped" inside a do block.

Are there any plans to address this situation? I believe there should be
a single, obvious and convenient way of handling errors in the language.

func attempt<T>(_ expression: @autoclosure () throws -> T, handler: (ErrorProtocol) -> T) -> T {
    do {
        return try expression()
    } catch {
        return handler(error)
    }
}
let x = attempt(downloadDataOrThrow()) {
    print("Connection lost")
    return nil
}

It mimics guard statement. You can also have versions of attempt with
partially defined handlers, like “return nil“ or “print and crash”, or
“assert type of error”.
​

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