@Anton: We still allowed to discuss it now. :) That won’t bother people that
much.
Just a side note without reading all the stuff going on here.
As much as I would love to have some type safety error handling, I do believe
it should be optional in first place.
Image some scenario like this:
func foo() throws AError {}
func boo() throws BError {}
func zoo() throws CError {}
// We also need some design to handle all errors at once:
func handle() rethrows AError & BError & CError -> ReturnType {}
// As you can imagine the line might become really long and ugly looking
// Merging with existential syntax or typealias?
func handle() rethrows Any<AError, BError, CError> -> ReturnType {}
typealias ABCError = AError & BError & CError
func handle() rethrows ABCError -> ReturnType {}
// But sometime you don't really care which error type might be thrown and your
API handles it with some other convention (docs?)
func handle() rethrows -> ReturnType {
try foo()
try boo()
try zoo()
return ReturnType()
}
A mix of a type safe and the current error handling mechanism would be great,
but not just the type safe (except we’ll get AnyError, where just re-/throws
might be a shorthand form for re-/throws AnyError)._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
