Your question illustrates exactly the problem that I'm trying to highlight. There is no one class of API in the world. Different APIs have different constraints, Swift shouldn't try to force square pegs into round holes.
To reunderscore the point, low level libraries end up being very different than application level frameworks: and in many cases it isn't /useful/ to allow evolution of failure models in this code. Take a look at one familiar body of code: the Swift standard library. It currently only throw two different concrete types of errors: DecodingError from codable stuff, and UTF8ValidationError from string stuff (note that the codable API is an example of where untyped throws is really important, because it calls into client code that can throw domain specific errors).
My point is that the Swift standard library is a large body of code that mostly doesn't need this, because Swift already has a way of typing the failure models: it already supports returning a value as an optional instead of throwing an error. The many APIs that use this are already admitting that they are closed to error handling evolution.
There is a wholly separate discussion about "how to be design a specific API". I agree that we don't want to see adoption of typed errors as the default for large scale APIs, but remember that we already have this problem: APIs can be built to return Result today.
Typed errors might not be the best answer to the problem "I don't know what errors this API throws", but relying on documentation is far worse. The compiler knows what errors are thrown and that is the only source of truth. Documentation quite often gets stale and does not reflect what the code is really doing. Reporting this somehow should be the compiler's responsibility. I haven't thought it through enough to propose something better than typed errors to solve this problem, but I think it's still better than what we currently have.
To me, this suggests that that typed throws would work better in a language with union types/anonymous sum types:
func throwingWithCallback<E>(callback: () throws E -> Void) throws (E | SomeSpecificError)
But anyway. Like all positions on typed errors, this applies equally to Result types. Regardless of whether typed errors are good or bad, having different choices for throws and Result is an unpleasant wart, and we have examples in this thread of people choosing Result when throws would be more ergonomic purely in order to use typed errors. If the goal of not having typed throws is to prevent people from creating bad APIs, it has clearly failed.
Just want to announce that @torstenlehmann and I have been debating into creating a pitch and here you have the first draft. I'd gladly expect feedback and feel free to make pull requests into it. When we feel it is finished we can go through the pitch forum!
In Objective-C, all current throwing functions had an implicit type in the function signature: NSError , and, as has been pointed out, this does not provide more information that the current generic Error . But developers were free to subclass NSError and add it to its methods knowing that, the client would know at call time which kind of error would be raised if something went wrong.
How so? As far as I know there is no way to mark that obj-c method throws at all, let alone what specific type it throws
#import "MyClass.h"
#import "MyError.h"
@implementation MyClass
-(void)testMethod {
// there are no indications at call site
[self throwingMethod];
}
// there are no indication of throwing at the method definition
-(void)throwingMethod {
@throw [[MyError alloc] init];
}
@end
Ah, but there is a way to throw in obj-c! It's even less typed than the one in swift. Try adding the code snippet above, and these supplementary files, and call testMethod from somewhere :)
Furthermore, since Result already exists and is a perfectly valid type, I think integration with the new Typed Throws feature is a given. Namely, the âgetâ method should be typed:
extension Result {
func get() throws Failure -> Success
}
Lastly, I think some more information on the source comparability compatibility effects of âTypingâ and âUntypingâ âthrowsâ would be much appreciated by the community. This, of course, isnât a very complex behavior, however failing to mention it seems irresponsible. Moreover, Library Evolution didnât seem to be given much thought with no mention of how non â@frozenâ enum error types would be treated. Discussing this, though, is integral to its adoption by libraries. There is an existing behavior in place that forces non âfrozenâ enums to be handled appropriately in âswitchâ statements (the compiler forces such switch statements to add an â@unknown defaultâ case). I think discussing this point in the proposal is crucial.
Other than that the proposal looks quite good at first glance.
I have a couple other questions I'd like to see addressed in the proposal:
What are the subtyping rules for typed-throws function types? E.g.,
class BaseError: Error {}
class SubError: BaseError, Error {}
let f1: () -> Void = { ... }
let f2: () throws SubError -> Void = f1 // OK?
let f3: () throws BaseError -> Void = f2 // OK?
let f4: () throws -> Void = f3 // OK?
Do we ever infer the throws type?
enum E: Error {
case failure
}
func f<T>(_: () throws T -> Void) { print(T.self) }
f({ throw E.failure }) // Does this compile? What does it print, if so?
I am strongly in favor of supporting typed errors, but I am strongly opposed to supporting any attempt to support throwing more than one error. Such a thing breaks consistency with Result, and adds significant complexity to the language.
You can argue that such an extension improves the expressivity for certain cases (e.g. the one above) but I think such an extension would be a bridge too far.
Yes we thought about that but consistency with Result takes priority because that will lead to the possibility (at least at some point) to use throws and Result interchangeably. We are already working on a section in the draft mentioning this.
(Meant to write compatibility there; sorry for any confusion.)
To elaborate on my point I think the proposal should explicitly mention how changing a âthrowsâ from a typed to an untyped form and vice versa will affect a libraryâs source comparability.
For instance, consider this function:
func fooThrower() throws
Are we allowed to change it to the following - while remaining source compatible?
func fooThrower() throws Foo
My intuition tells me âYes!â - since Foo is an âErrorâ after all. So letâs see, the code for handling the former function would probably look like this:
do { try fooThrower() }
catch let error as? Foo { ... }
Which means that by changing to the latter function clients rebuilding will get a warning (saying that error is Foo). That, however, doesnât really sound like source compatibility. Hence, I think that explicitly stating that to API designers is important.
Furthermore, while on the note of exploring source compatibility effects, a brief mention to the source breaking effects of typing a throw would fit in well, in my opinion.
The other thing I was concerned about in regards to source compatibility was the handling of non âfrozenâ enums in library evolution mode. Iâm glad to see, though, that this issue has been addressed in the proposal.
Even if the type would be a variadic generic enum with index enumerated cases provided by the stdlib that itself conditionally conforms to Error when all type parameters conform to Error?
then throwers would presumably be inferred as Array<() throws Foo -> ()>. Then, the line throwers.append(generalThrower) would become an error, since generalThrower may throw non-Foos!
As far as I understood @filip-sakel we should collect these issues and just formulate a guideline for API implementers. But yes updating a function that throws a Swift.Error to a more specific error needs to assumed as a breaking change.
