Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Allow Type Annotations for throws #26

Closed
wants to merge 2 commits into from
Closed

Proposal: Allow Type Annotations for throws #26

wants to merge 2 commits into from

Conversation

owensd
Copy link

@owensd owensd commented Dec 4, 2015

This is a proposal to allow typed throws annotations primarily for the purpose of increased code clarity by moving what are currently run-time validations to compile-time validations.

@gribozavr
Copy link
Collaborator

The proposal seems to be ignoring the negative implementation experience in Java. Why is Swift different?

@owensd
Copy link
Author

owensd commented Dec 5, 2015

I guess first and foremost, the proposal basically boils down to a syntactical sugar request for what could be considered Error<T> and Result<T, U> types as the realized return values.

The second fundamental ask is this: give us the ability to handle errors in a way that we can verify all of the potential codepaths with the compiler.

My experience in Java was many years ago, so I can only speak to what I remember, but what I do remember was the proliferation of exceptions for every little minute thing. In the end, they became a mechanism for control flow instead of for actual error cases.

An example would be a FileNotFoundException. Is it really exceptional that a file doesn't exist? No, obviously not. Bad API decisions cannot help you abuse language constructs.

The other problem seemed to be the shear number of exceptions that would be marked as throwable from any particular method. In the proposal, I specifically call out only allowing a single type. The purpose is to avoid such a proliferation problem.

This is what all of my do-catch code boils down to:

do {
    try f()
}
catch KnownError.Case1 { }
catch KnownError.ThatsAllOfThem {}
catch { fatalError("Well... if someone else adds another case, I better crash here and hopefully I'll see it before my customers do") }

Now, if I chose to use a catch-all catch clause, then that's fine. However, Swift forces me to do it today. So my option is to either:

  1. Crash the user's app so that a potentially subtle bug doesn't propagate through the app causing a more serious error, or
  2. Roll the dice and see what happens. Hopefully I have telemetry data here so I know when these handlers are happening, because the compiler cannot tell me.

If you have another option, I'm willing to hear it.

@DougGregor
Copy link
Member

Please move commentary to the swift-evolution mailing list!

@apple apple locked and limited conversation to collaborators Dec 5, 2015
@DougGregor
Copy link
Member

This proposal isn't ready for a full review yet. There is some technical detail that really needs to be addressed for such a proposal (e.g., how it interacts with generics, overriding and rethrows) and the rationale needs to be expanded to discuss some of the major points brought up in the discussions (e.g., listing specific exception types is generally considered a problem in Java and also in C++, where it's been deprecated).

@DougGregor DougGregor closed this Dec 12, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants