First 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,
}
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.
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.
···
On Dec 4, 2015, at 4:04 PM, Manav Gabhawala <manav1907@gmail.com> wrote:
}
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,
Adrian Kashivskyy
iOS Developer at Netguru
···
Wiadomość napisana przez John McCall <rjmccall@apple.com> w dniu 05.12.2015, o godz. 01:15:
On Dec 4, 2015, at 4:04 PM, Manav Gabhawala <manav1907@gmail.com <mailto:manav1907@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.
}
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.
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@me.com> a écrit :
Regards,
Adrian Kashivskyy
iOS Developer at Netguru
Wiadomość napisana przez John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> w dniu 05.12.2015, o godz. 01:15:
On Dec 4, 2015, at 4:04 PM, Manav Gabhawala <manav1907@gmail.com <mailto:manav1907@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.
}
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.