I don't know how this became a discussion for specifying errors when throwing but +1 on the off chance that this thread is actually used to gauge interest.
On Tue, Dec 27, 2016 at 10:27 PM, Daniel Leping via swift-evolution < [email protected]> wrote: > -1 for checked exceptions. Don't make it java. For thous interested why, > just google. It's common frustration in Java world so the info is > everywhere. > > In general you end up with wrapping and wrapping and wrapping the fine > grained exceptions into general ones. And you have more exception classes > than functional ones. Please, don't go this path. > > On Wed, 28 Dec 2016 at 3:46 thislooksfun via swift-evolution < > [email protected]> wrote: > >> That's fair. The reasoning I read about mentioned making it easier for >> newcomers, but it's very possible that was a 3rd party opinion (I don't >> remember). I certainly did not intend to upset anyone. >> >> Either way, I do still believe that the current placement / syntax isn't >> entirely clear. >> >> >> >> -thislooksfun (tlf) >> >> >> >> >> >> >> >> On Dec 27, 2016, at 4:09 PM, Xiaodi Wu <[email protected]> wrote: >> >> Offlist on purpose? >> >> On Tue, Dec 27, 2016 at 5:03 PM, thislooksfun <[email protected]> >> wrote: >> >> Thinking about it logically, it's placement does fit, yes. >> >> >> :) That's all one can ask. >> >> >> I'm not debating that the current placement is logical once you get used >> to it, but on a related note, so are ++ and --, which were removed to make >> the language easier and more immediately intuitive for new programmers. >> >> >> Bringing up ++ and -- on the list just makes everyone unhappy; also, >> classical for;; loops. It's like Godwin's law for Swift Evolution :P >> >> But FWIW, making it easier for new programmers was not the whole >> rationale (or, if I recall, even a large part of it). There's a whole >> school of thought in language design that removing ++ and -- and for;; >> loops is the _more logical_ thing to do from a modern language design >> perspective. I don't have the link, but there was an article recently >> evaluating Rust, Go, Swift, and a bunch of other C-family languages for the >> "quality" of their design. An opinionated piece, to be sure, but having ++ >> and for;; were regarded as negatives that languages would lose points for. >> So let's be clear that it's not a way of thinking that originated from >> Swift wanting to help beginners, nor is it even limited to Swift at all. >> >> >> My only point was that if they are willing to go to such lengths to make >> the language easy to understand as to remove a very well known feature like >> the incremention and decremention operators, maybe the placement of >> `throws` should be reviewed to make sure it's also intuitive. >> >> >> >> -thislooksfun (tlf) >> >> >> >> >> >> >> >> On Dec 27, 2016, at 3:58 PM, Xiaodi Wu <[email protected]> wrote: >> >> Agree, it doesn't seem to read naturally at first glance. >> >> However, one way perhaps to think about the rationale for this is that >> `throws` does "fit" logically between the parameters and the return type: a >> function that throws might take certain arguments and, by throwing, never >> return a value of the stated return type. In that perspective, `throws` >> could be justified in its current position interposed between the input and >> the desired output. >> >> >> On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution <swift- >> [email protected]> wrote: >> >> 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. >> >> >> I'm -1 on big changes such as suggested as well. The deliberate choice to >> separate error handling from other code with `do { }` was a deliberate >> design choice and it'd be very disruptive to break that now. And in terms >> of just gut feeling, switching over errors and return values at the same >> time seems like going in the wrong direction. >> >> >> - Karl >> >> On 27 Dec 2016, at 22:31, Derrick Ho <[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]> wrote: >> >> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <swift- >> [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]> >> wrote: >> >> On 27 Dec 2016, at 13:43, Tino Heth <[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] >> 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 >> >> >> _______________________________________________ >> >> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
