If some form of explicitly typed errors is added, my initial problem goes away. The only reason I suggested the move in the first place, is that a combination of `throws` and return (-> T) statements makes it look like there is already explicitly typed errors, especially to those of us coming from Java.
-thislooksfun (tlf) > On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution > <[email protected]> wrote: > > Moving “throws” or changing it to a prefix “throwing” as was originally > suggested are relatively minor, reasonable improvements. > > We do need to consider if it restricts future language evolution (such as > potentially listing all of the thrown errors), so that’s why it’s relevant to > talk a little bit about that and what are options would be; but I think > fundamental, non-backwards compatible changes to how you invoke throwing > functions are probably too big to be reasonable. > > - Karl > >> On 27 Dec 2016, at 22:31, Derrick Ho <[email protected] >> <mailto:[email protected]>> wrote: >> >> Right. it should support the normal return type as well as the errors. Here >> is my revised suggestion. >> >> func foo() throws -> String {} >> >> switch try foo() { >> case .returnValue(let value): >> // do something with value >> >> case .MyEnumErrorFirstError: >> // handle error >> >> default: >> // handle NSError >> } >> On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> I suppose "throws" could be enhanced to produce a compiletime enum >> >> func bar() throws { >> throw NSError() >> throw MyEnumError.firstError >> } >> >> Under the hood each expression passed to "throw" could make something like >> >> enum bar_abcdefj_throw { >> case genericError // all NSError go here >> case MyEnumErrorFirstError >> } >> >> Where abcdefj is unique characters. >> >> >> This enum would only be visible through the catch blocks which would act >> like a switch statement. >> >> Speaking of switch statements do they currently support "try" expressions? >> >> switch try foo() { >> case .MyEnumErrorFirstError: >> // handle error >> default: >> // handle NSError and everything else >> } >> >> If I'm not mistaken, `switch try foo()` switches over the return value of >> foo(); you'd switch over the error in a catch block. >> >> The benefit of this approach is that it would be additive. And no source >> breakage. >> >> At the risk of being off topic if there is interest in this I can start a >> new thread for this. >> >> On Tue, Dec 27, 2016 at 9:54 AM Haravikk <[email protected] >> <mailto:[email protected]>> wrote: >>> On 27 Dec 2016, at 13:43, Tino Heth <[email protected] <mailto:[email protected]>> >>> wrote: >>> Imho this is no problem: >>> Right now, we basically have "throws Error", and no matter what is actually >>> thrown, we can always catch exhaustive by keeping the statement unspecific. >> >> True, but for me it's more about knowing what a method can throw; currently >> to know that you need to consult documentation which, while fine, isn't the >> best way to do that when the compiler could know and it's then up to you >> whether to let it auto-complete for all throwable types, or just be generic >> for some or all of them (or pass the buck). >> >>>> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … } >>> Imho to much confusion with no real benefit: >>> Shouldn't it be up to the caller to decide which errors need special >>> treatment? The library can't enforce proper handling at all. >> >> Partly, but it's really just intended to distinguish things that are genuine >> runtime errors, versus things that shouldn't have happened, i.e- an illegal >> argument type error shouldn't occur if you're using a method correctly, so >> it's more like something you might check as an assertion. I should have been >> more clear that the main difference is in how fix-its might recommend the >> errors are handled; specific types would produce catch blocks, but optionals >> might be grouped into a catch-all at the end (e.g- they're special interest >> that you might not be bothered about), but the compiler would still be aware >> of them should you decide to add them. >> >> If the distinctions not significant enough though then the "optional" error >> types could just be ignored for now, I think the more important ability is >> the ellipsis indicating "plus other errors" so we can specify either >> exhaustive lists of error types, or keep them open-ended, in which case the >> types listed are those that would be placed as catch blocks, with the >> ellipsis indicating that a catch-all is still required (or throw on the >> current method). >> >>> One thing to note with explicit errors is that we'd basically introduce sum >>> types… >> >> >> Not necessarily; you could think of explicit errors as being doing something >> like: >> >> enum MyErrorType { >> case io_error(IOError) >> case illegal_argument(IllegalArgumentError) >> case unknown(Error) >> } >> >> i.e- boilerplate we could do right now, but would prefer not to, but still >> allowing it to be handled as an enum. >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
