[swift-evolution] Remove Failable Initializers

Tue Mar 8 06:10:03 CST 2016

Interestingly what Haravikk describes is mentioned here.

http://ericasadun.com/2015/08/27/capturing-context-swiftlang/

This approach is very similar to Rubys

*___________________________________*

*James⎥Head of Trolls*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Tue, Mar 8, 2016 at 10:07 AM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On 8 Mar 2016, at 01:21, Brent Royal-Gordon <brent at architechies.com>
> wrote:
> >
> >> A duplicate shouldn’t be necessary; functions/initialisers that can
> throw just need to be called with a flag indicating whether they should
> capture or ignore errors as appropriate for try vs try? and try!. Any
> statement that is identified as being specific to a throw is then wrapped
> in a conditional based on this flag so it can be skipped if errors are
> ignored.
> >
> > Okay, so you're passing in what amounts to a new parameter (which is
> going to take up a register or some stack space that could be used for
> something else) and adding a new conditional branch at each throw site. In
> cases where a `try` is nested directly inside a `throws` function, you
> might need a conditional branch at the return site, too. (Remember, CPUs
> hate conditional branches.)
>
> It’s a conditional that should only have an impact when an error is being
> (or about to be) thrown, also I don’t think that a conditional at the call
> site would be necessary; if you know that try? or try! was used then you
> know that the flag was passed and that you’ll get no error instance back,
> just whatever usually passes the error status.
>
> > I think that your use of the word "laziness" is telling. You are
> assuming that, if someone doesn't throw detailed errors, they are being
> lazy.
>
> You’re assuming that every error has to be as detailed as possible ;)
>
> I’m working from the assumption that part of updating the standard library
> to remove failable initialisers would include creating a set of common
> errors that developers can use too if they like. For example, yes,
> InvalidParameterError wouldn’t be super informative (though it at least
> informs you that the issue was with the parameter itself, and not something
> else that failed internally), however if there were errors for non-numeric
> input and such that this could provide extra information. You can certainly
> argue that it could still provide more information, but if we’re
> considering all failable initialisers to be “simple” then there will be a
> point at which you’re providing more information than anyone is actually
> going to use; a developer can certainly choose to do-so, but ultimately
> there may still be cases where just knowing that there was an error, or an
> error of a particular type, is enough.
>
> > To illustrate, I spent ten or fifteen minutes examining
> IntegerParsing.swift.gyb so I could understand the failure cases of
> `Int.init(_:radix)`. To fully model all of the errors which can cause it to
> return `nil`, and without including any redundant information you could get
> from the string itself, you would probably need this enum:
> >
> >       enum IntFromStringError: ErrorType {
> >               case EmptyString
> >               case NoDigits
> >               case NegativeUnsigned
> >               case TooLarge (at: String.UTF16View.Index)
> >               case NonDigit (at: String.UTF16View.Index)
> >               case DigitBeyondRadix (at: String.UTF16View.Index)
> >       }
> >
> > if your answer is "Don't do all that, just lump everything together into
> one vague error", then why are we using the throwing mechanism in the first
> place? Failable initializers convey one vague error just as well and with
> much less fuss.
>
> My answer would be more along the lines of “just lump everything together
> into reasonably specific errors”. For example, EmptyString and NoDigits
> could easily be handled by a general purpose non-numeric error, while the
> rest could be handled by an integer out of range error of some kind; that
> should be plenty to communicate the problem, while detail messages could
> provide further information to the developer if the error is coming up
> unexpectedly (e.g- from input you thought was safe).
>
> Instead of “something was wrong” you would then have two possibilities for
> what was wrong, and the potential to get more information if you need it
> during testing.
>
> > If an error should only occur during debugging, it should be a
> precondition, not a failable *or* throwing initializer.
> >
> > By definition, any throwable error should be something you expect to
> happen in the normal course of running the code out in the wild. That means
> there needs to be enough detail to either automatically fix the problem or
> usefully present it to a user, either textually or with some kind of
> graphical representation (like pointing to the invalid character).
>
> Not quite what I meant; I would absolutely expect the error to occur in
> the wild, and be caught or ignored as appropriate, the message is just for
> cases where you’re not sure why it’s occurred in the first place, i.e- the
> error (and its type) is often enough all you need in simpler error cases,
> but if you’re getting them unexpectedly rather than due to anticipated
> mistakes in input etc. then you may want the extra detail. You certainly
> could model it for programmatic inspection and that’s an option too, but it
> may not be necessary.
>
> Just because someone opts to use error handling over a failable
> initialiser doesn’t mean they have to go overboard on the detail of their
> errors; it’s entirely possible to pick a reasonable middle-ground. In other
> words, the work you put in should absolutely reflect some kind of value,
> but you seem to be assuming that the maximum possible amount of work has to
> be put into every error type thrown, where I think that most simple errors
> can be adequately modelled from a decent set of default error types;
> anything more complex absolutely should go into more detail as appropriate,
> but again they don’t necessarily have to expose the most minute of details.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160308/f8196511/attachment.html>