[swift-evolution] Type Inferencing For Error Handling (try catch blocks)

[Jean-Daniel Dupas]

One problem I see with that pattern, is that the exception declared will be part of the ABI, and adding a new exception will break backward compatibility.

As one goal of swift 3 is to provide a stable ABI by working around fragile ABI pattern, adding such a feature would probably be very difficult, and maybe not worth it.

> Le 5 déc. 2015 à 11:18, Adrian Kashivskyy <adrian.kashivskyy at me.com> a écrit :
> 
> Related: https://lists.swift.org/pipermail/swift-evolution/2015-December/000076.html <https://lists.swift.org/pipermail/swift-evolution/2015-December/000076.html>
> 
> Regards,
> Adrian Kashivskyy
> iOS Developer at Netguru
> 
>> Wiadomość napisana przez John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> w dniu 05.12.2015, o godz. 01:15:
>> 
>>> On Dec 4, 2015, at 4:04 PM, Manav Gabhawala <manav1907 at gmail.com <mailto:manav1907 at gmail.com>> wrote:
>>> irst of all, Swift is an absolute dream of a programming language and is really taking the future of programming in the right direction.
>>> 
>>> However, it seems backwards to me that everything in swift is type safe and complete (like enum cases) but error handling seems lacking on that end. It would be a huge feature if the compiler could infer the types of errors functions throw and make sure you catch all the different types of errors at the call site. The compiler could also chain the types through multiple throwing function callers. This feature would require no extra work on the programmers part because the compiler would infer the types of errors being thrown. For example,
>> 
>> This is a global type-checking problem.  It’s completely blocked by any dynamic features (like protocol or class methods) and library boundaries, so outside of toy examples, you will end up needing exhaustive pattern-matching pretty much everywhere.
>> 
>> John.
>> 
>> 
>>> 
>>> 
>>> func foo() throws
>>> {
>>> 	...
>>> 	throw ErrorType1.BadRequest
>>> 	...
>>> 	throw ErrorType1.NoAuthentication
>>> 	...
>>> 	throw ErrorType2.NoResourceFound
>>> }
>>> func main()
>>> {
>>> 	do 
>>> 	{
>>> 		foo()
>>> 	}
>>> 	catch (ErrorType1.BadRequest)
>>> 	{
>>> 		
>>> 	}
>>> 	catch (ErrorType2.NoResourceFound)
>>> 	{
>>> 	}
>>> 	// Compiler error because ErrorType1.NoAuthentication is not included.
>>> }
>>> 
>>> Errors can also be chained together such that each function statically identifies the types thrown and if a call is made to a throwing function all the uncaught types are propagated out of the call stack. This would firstly be beneficial because we wouldn’t need the ridiculous empty catch { } block at the end that most people end up doing and secondly would ensure programmers are completely and always aware the possible errors that can be thrown by the function calls they make.
>>> 
>>> Regards,
>>> Manav
>>> 
>>>  _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151205/b510c805/attachment-0001.html>