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