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

John McCall rjmccall at apple.com
Fri Dec 4 18:15:21 CST 2015


> On Dec 4, 2015, at 4:04 PM, Manav Gabhawala <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>

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


More information about the swift-evolution mailing list