> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier <[email protected]> wrote:
>
> Please see comments inline.
>
>> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>>> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution
>>>> <[email protected]> wrote:
>>>>
>>>> So “try” instead of “do”. If there is no catch, then just use braces
>>>> without a keyword for a block.
>>>>
>>>> And use do-while instead of repeat-while.
>>
>> +1
>>
>>>
>>> Do you also propose no longer marking calls to throwing functions with
>>> `try`?
>>
>> If try had both a single-statement/expression form as it does today, and a
>> block form that makes it unnecessary to mark all the individual statements
>> in the block, that would be an improvement.
>>
>>> Have you read the "Error-Handling Rationale" document in the Swift
>>> repository? If not, please do:
>>> <https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst>
>>> If so, please explain why you disagree with it.
>>
>> There are large classes of programs where you can know you don’t care
>> exactly where a failure happens, e.g. (most init functions, all pure
>> functions, any function that doesn’t break invariants). In these cases
>> marking every statement or expression that can throw is just noise. Try
>> writing some serialization/deserialization code where the underlying stream
>> can fail to see what I mean; you’ll have “try” everwhere, and it adds
>> nothing to comprehensibility or maintainability. Personally I would like to
>> be able to label the function itself and not have to introuce a scope, but
>> IMO being able to create “try blocks” would be a welcome addition and would
>> even match the common case in blocks with catch clauses, where being aware
>> of the exact line where the error was generated is typically not useful.
>
> I had proposed something very similar to this around six months ago on the
> swift-users list, but I think John McCall, had some (quite valid) concerns
> with this.
>
> Unfortunately I can't access those emails, but I think his concern was that
> the purpose of try was to mark explicitly which statements throw and this
> would defeat the purpose of that. People might just wrap large blocks in try.
As much as I am loath to disagree with John on this, there’s an incorrect
implicit assumption in that rationale, that forcing people to mark all throw
points trains them to get error-handling correct. What it does instead is to
train them to think of all code uniformly instead of recognizing the places
where a throw needs special attention (places where there are broken
invariants). Eventually, as with warnings that have a high false-positive
rate, when you see “try” in many places where it doesn’t help, you learn to
ignore it altogether.
>
> Another idea is to treat the block as an unnamed, no argument, no return
> value, function that could throw. This solves the problem in a very general
> way, and would retain the marking of all throwing functions with try,
That marking, in itself, is the root problem. Our syntax is the way it is
primarily because "marking everywhere" was adopted as an explicit goal.
> but has the perhaps unfortunate syntax of allowing things like:
>
> try {
> try myFunction()
> } catch {
>
> }
>
> Something like this could be shortened to a consistent theoretical inline try
> catch syntax like:
>
> try myFunction() catch {
>
> }
>
> Though, as John, pointed out at the time, this could still be added on with
> the current syntax. Obviously treating a try like an unnamed function would
> have different return semantics, so perhaps that's not the right abstraction.
> (Although I recall a thread going on that is considering allowing functions
> to retain return semantics of the outer scope)
>
> Tyler
>
>
>>
>> -Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
