[swift-users] [swift-evolution] Best way to handle escaping function that might throw
Howard Lovatt
howard.lovatt at gmail.com
Wed Jan 11 16:06:44 CST 2017
Yes, I have used Result in the past.
In this case I wanted to use throws because that is what functions like map
do.
Looks like I will have to stick with throwing, not too bad since the
overhead is reasonably low.
On Wed, 11 Jan 2017 at 8:03 am, T.J. Usiyan <griotspeak at gmail.com> wrote:
> I suggest using an enum to represent success and failure. It's usually
> referred to as `Result`. It might seem weird for the closure that you
> presented as an example, since it would be Result<Void>, but it properly
> captures the possibility of having thrown.
>
> ``` swift
> enum UselessError : Swift.Error {
> case somethingBadHappened
> }
>
>
> enum Result<T> {
> case success(T)
> case failure(Swift.Error)
>
> init(throwingClosure: (Void) throws -> T) {
> do {
> self = try .success(throwingClosure())
> } catch {
> self = .failure(error)
> }
> }
> }
>
> func burnItDown() throws -> Void {
> throw UselessError.somethingBadHappened
> }
>
> Result(throwingClosure: burnItDown)
> ```
>
>
>
> On Mon, Jan 9, 2017 at 10:28 PM, Jacob Bandes-Storch via swift-users <
> swift-users at swift.org> wrote:
>
> Moving to swift-users list.
>
> No, there's no way to do this today. The point of rethrows is that within
> one call site, "f(block)" can be treated as throwing if the block throws,
> or not throwing if the block doesn't throw. In your example, once the
> FStore object is constructed, the information about the original passed-in
> function is lost, so the caller has no way to know whether call() can throw
> or not.
>
> If this *were* possible, the information would somehow need to be encoded
> in the type system when creating FStore(f: block). That would require
> something like dependent typing, or generic-param-based-rethrows, e.g.
>
> struct FStore<T: () throws -> Void> { // made-up syntax
> let f: T
> func call() rethrows(T) { try f() } // throws-ness of this function
> depends on throws-ness of T
> }
>
>
>
> On Mon, Jan 9, 2017 at 9:21 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi,
>
> If I have an escaping function that I store and then call, I need to
> declare the calling function as throwing, not rethrowing. EG:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> struct FStore {
> let f: () throws -> Void
> init(f: @escaping () throws -> Void) { self.f = f }
> func call() throws { try f() } // Can't put rethrows here - have
> to use throws
> }
> Is there a better solution?
>
> Thanks for any suggestions,
>
> -- Howard.
>
>
>
>
>
> _______________________________________________
>
>
> swift-evolution mailing list
>
>
> swift-evolution at swift.org
>
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
>
>
>
> _______________________________________________
>
>
> swift-users mailing list
>
>
> swift-users at swift.org
>
>
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
>
>
>
> --
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170111/06dc9229/attachment.html>
More information about the swift-users
mailing list