In a block of code where errors are only thrown in some places, do+try is
illustrative because it allows you to know which functions are possible failure
points.
However, in a block of code where errors are thrown in most places, a try block
would be useful because individual try statements become noise.
Comments:
1. I was under the impression that the second case was not expected to be the
norm in swift code when the error functionality was added.
2. It seems like in either case, a try block would be less typing than a do+try
block. I don’t know if this would lead to do blocks not being used in cases
where doing so would improve code comprehension.
3. Using try in this manner also has the potential (positive and negative) of
having c++ style try/catch, but with different mechanics (as we are dealing
with errors and not exceptions).
One possible approach if it was desirable to not have this used arbitrarily in
place of do+try, and to avoid looking too much like exception syntax: instead
define rethrows blocks:
func recognizeHandler() throws {
rethrows {
accept(.on) // .on is an enum tag for the token for the ‘on’
keyword.
recognizeName()
recognizeFormalParamSeq()
accept(.newline)
recognizeCommandSeq()
accept(.end)
recognizeName() // Later Visitor pass checks that names match.
accept(.newline)
}
}
A rethrows block does not allow catch blocks to be attached. To catch any of
the errors, you would still need to use do+try, which means do+try would still
be used in cases where it was illustrative. There is an extra level of
indentation, but at four character indentation this would not make the lines of
code any longer (since you eliminated “try “). There is no syntax mismatch with
existing languages with exception semantics to cause confusion.
Comments?
-DW
> On Jan 3, 2016, at 10:58 AM, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>>
>>>> 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.
>>>
>>> That's a really interesting idea, but I don't think it's what the poster
>>> was suggesting. It sounded to me like he was merely saying “let's make the
>>> Swift error system look like my favorite language's exception system".
>>
>> I agree with Brent’s assessment of the OP. However that doesn’t mean that
>> Dave does not have a good point. Here is some code from a recursive descent
>> parser. (More correctly: the recognizer. Omitting the AST-building stuff.)
>>
>> func recognizeHandler() throws {
>> try accept(.on) // .on is an enum tag for the token for the
>> ‘on’ keyword.
>> try recognizeName()
>> try recognizeFormalParamSeq()
>> try accept(.newline)
>> try recognizeCommandSeq()
>> try accept(.end)
>> try recognizeName() // Later Visitor pass checks that names match.
>> try accept(.newline)
>> }
>>
>> There is a lot more where that came from.
>
> Exactly. The natural response from framework designers is to find more ways
> to support writing entire functions as a single expression. At the limit,
> you end up with
> http://www.boost.org/doc/libs/1_60_0/libs/phoenix/doc/html/phoenix/modules/statement.html
>
> <http://www.boost.org/doc/libs/1_60_0/libs/phoenix/doc/html/phoenix/modules/statement.html>.
>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
