Re: [swift-evolution] A unified error handling mechanism?

[Jose Cheyo Jimenez via swift-evolution]

Hi Fernando, 

Some projects use a result type to unify the error handling. 
https://github.com/antitypical/Result 

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 
>  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?
> 
> 
> 
> -- 
> 
> 
> 
>  
> 
> Fernando Rodríguez
> m. +34 610 965 332
> t. +34 91 629 57 61
> fernando@k eepcoding.io 
>   
> 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

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

Re: [swift-evolution] A unified error handling mechanism?

[Xiaodi Wu via swift-evolution]

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 :
>
> 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(_ 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A unified error handling mechanism?

[Anton Zhilin via swift-evolution]

2016-08-06 2:50 GMT+03:00 Fernando Rodríguez :

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(_ 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

Re: [swift-evolution] A unified error handling mechanism?

[Anders Ha via swift-evolution]

> On 6 Aug 2016, at 7:50 AM, Fernando Rodríguez via swift-evolution 
>  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.

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)

> 
> 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?
> 
> 
> 
> -- 
> 
> 
> 
>  
> 
> Fernando Rodríguez
> m. +34 610 965 332
> t. +34 91 629 57 61
> fernando@k eepcoding.io 
>   
> 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

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

Re: [swift-evolution] A unified error handling mechanism?

[Boris Wang via swift-evolution]

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 于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?
>
>
>
> --
>
>
> * *
>
>
> *Fernando Rodríguez*
>
> m. +34 610 965 332
>
> t. +34 91 629 57 61
>
> fernando@k 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] A unified error handling mechanism?

[Fernando Rodríguez via swift-evolution]

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?



-- 


* *


*Fernando Rodríguez*

m. +34 610 965 332

t. +34 91 629 57 61

fernando@k 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