I think the clear middle ground is an approach where you *can* document the
type, but let it not be required.
Additionally, we can treat that at the calling end as a built time assurance of
the type for error that is passed into the standard “catch { }”, and the
compiler can also check that all of your catch let … casts actually are
possible, and so catching becomes like a switch. I don’t see this as changing
anything we currently do, except giving us the option to declare more than the
current: Currently “throws” means “throws Error”. Why can’t we allow more
information to be passed?
I think the compiler needs to remove the overhead of specified error types.
Just like Java may be seen as a nightmare, it’s clear here that the fact we can
specify different error types means *guessing* the error types is just as much
of a nightmare. It makes sense, even if only for documentation reasons, to
allow a declarable way of denoting your error type, and feeding that
information to the compiler for built time checks.
> On 27 Dec 2016, at 10:20 pm, Charlie Monroe via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> For me, handling Swift errors is a nightmare. You have no idea what to expect
> to be thrown. Some developers use NSError for use with Cocoa/UIKit (usually
> errors meant for user interaction), but some use enums that even can have a
> payload (extra info about the error). And you need to rely on the
> documentation, which can be nonexistent or inaccurate. Not to mention, within
> that call, another throwing method can be called, which may not be mentioned
> in the docs, which may result in other error types being thrown.
>
> And mainly, when the docs mention that only MyErrorEnum can be thrown, you
> have a catch branch for MyErrorEnum, but the compiler will complain that not
> all cases are handled. So you either need to catch a generic Error and
> force-cast it, or add another catch _ branch calling fatalError - unhandled
> error. Either way, not a pretty solution.
>
> While I always hated Java's approach of listing all exceptions that can be
> thrown, I equally hate current state of Swift, where you have no idea what's
> comming at ya. In ObjC, you knew it was NSError. Yes, you still can bridge
> any Error to NSError, but you loose a lot of potentially useful information
> about the error.
>
>
>> On Dec 27, 2016, at 10:57 AM, Daniel Leping via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> -1 for specifying errors for throws. Please don't. Proven by practice in
>> java it's a nightmare.
>>
>> On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> I like the idea of "throw" having information about what might be thrown.
>>
>> Maybe you have an enum of errors that may be thrown. How would the
>> programmer know what might get thrown if they don't know the implementation
>> details?
>>
>> While adding the throwing info in the comments is good, we might be better
>> off adding an attribute
>>
>> @throws(Error_Enum, Specific_error, ...)
>>
>> Where the stuff in parenthesis is a comma separated list of possible errors.
>> Maybe it's all the cases in enum are possible or maybe only a specific few
>> are used...
>>
>> Then we can do something like this
>>
>> @throws(MyErrorEnum)
>> func foo() {
>> ....
>> throw MyErrorEnum.firstError
>> ....
>> }
>>
>> With this info we can properly catch all error cases
>>
>> do {
>> try foo()
>> } catch MyErrorEnum.firstError {
>>
>> } catch {
>> }
>>
>> As for blocks that throw we could probably add it in the same place where
>> @escaping is.
>> On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Maybe we can let the compiler use documentation comments for type-checking.
>> Currently you can do:
>>
>> /// does something
>> ///
>> /// - returns: Something cool
>> ///
>> /// - throws:
>> /// - `MyError.Something` if a certain thing happens
>> /// - `POSIXError` if something goes horribly wrong
>> ///
>> func doSomething() throws -> Int
>>
>> I would prefer if we found some way to integrate that stuff in to the
>> compiler. I mean, you would probably want to document why the errors get
>> thrown anyway, and it’s better than clobbering up the function signature.
>>
>> Maybe it seems weird to have the compiler look inside comments (especially
>> if the set of thrown errors becomes a resilience-breaking part of the
>> function), but why not? Swift’s documentation comments are just another
>> source of structured data, and the compiler already understands them at a
>> superficial level.
>>
>> Just saying, there are options.
>>
>>> On 27 Dec 2016, at 07:55, Tony Allevato <tony.allev...@gmail.com
>>> <mailto:tony.allev...@gmail.com>> wrote:
>>>
>>> One thing to keep in mind is that, if I recall correctly, some members of
>>> the core team have expressed a desire to enhance `throws` by letting users
>>> list the specific error types that a function can throw. If that is
>>> something that might happen in the future, moving the `throws/throwing` to
>>> the front would add a significant amount of noise before the function name.
>>>
>>>
>>> On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> I agree that this could do with revision. It looks particularly ugly when
>>> you’re dealing with throwing closures.
>>>
>>> Recently I had a signature like:
>>>
>>> public func scan(length: File.ByteOffset.Stride?,
>>> by frameSize: File.ByteOffset.Stride,
>>> with handler: (_ range: Range<File.ByteOffset>, _
>>> data: UnsafeRawBufferPointer) throws -> Bool) throws ->
>>> File.ByteOffset.Stride
>>>
>>> It can get difficult to parse the signature towards the end. Marking the
>>> handler and function as throwing closer to the beginning would make it more
>>> readable IMO. One thing it allows me to do more easily is to remove the
>>> spaces around the arrow for the closure parameter (just a little thing
>>> which I find helps me read the trailing closure/return type more quickly).
>>>
>>> public throwing func scan(length: File.ByteOffset.Stride?,
>>> by frameSize:
>>> File.ByteOffset.Stride,
>>> with handler: throwing (_ range:
>>> Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer)->Bool) ->
>>> File.ByteOffset.Stride
>>>
>>> - Karl
>>>> On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>
>>>> Hello Swifters,
>>>>
>>>> I've been writing a lot more Swift code recently, and I have found that
>>>> the default placement of the 'throws' declaration is often confusing,
>>>> especially to those of us switching from languages where the type of
>>>> errors thrown is explicitly defined (like Java)
>>>>
>>>> For example,
>>>> // This is pretty clear, this can throw an error
>>>>
>>>> func foo() throws
>>>>
>>>> { ... }
>>>>
>>>>
>>>>
>>>> // Also pretty clear, this returns a String
>>>>
>>>> func bar() -> String
>>>>
>>>> { ... }
>>>>
>>>>
>>>>
>>>> // Confusing. Does this throw a String? Does it return a String? Does it
>>>> do both?
>>>>
>>>> // I personally keep reading this as 'this can throw a String'
>>>>
>>>> func baz() throws -> String
>>>>
>>>>
>>>>
>>>> // Equivalent code in Java (not a model, just for clarification of why the
>>>> above is confusing)
>>>>
>>>> String baz() throws StringFormatException
>>>> I therefore suggest either tweaking the syntax around, or moving, the
>>>> `throws` keyword to avoid this confusion.
>>>>
>>>> Some ideas I've had:
>>>> // Add a comma to separate them
>>>>
>>>> func baz() throws, -> String
>>>>
>>>>
>>>>
>>>> // Move `throws` to the end
>>>>
>>>> func baz() -> String throws
>>>>
>>>>
>>>>
>>>> // Change it to a prefix modifier (like `mutating`)
>>>>
>>>> throwing func baz() -> String
>>>>
>>>> I'm still not sold on any of the above syntaxes, but I would love to hear
>>>> your feedback.
>>>>
>>>> This would affect existing code, but it would be a fairly small change
>>>> that would result in very large readability improvements, especially for
>>>> newcomers, and especially for those coming for a language such as Java.
>>>>
>>>> -thislooksfun (tlf)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>>
>>>
>>> swift-evolution mailing list
>>>
>>>
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>
>>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>>
>>
>> swift-evolution mailing list
>>
>>
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>>
>> _______________________________________________
>>
>> swift-evolution mailing list
>>
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
