> On Jan 3, 2016, at 10:51 AM, David Waite <[email protected]> wrote:
>
> 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.
Whether the individal failure points are important to notice is not related to
how many of them there are; it’s a function of what your code is doing in
between and around them.
>
> 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.
That seems unlikely there is a large class of common applications that fall
into that bucket. In particular, anything likely to be coupled to I/O tends to
be like that.
> 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.
Sure; I wanted that to be the meaning of the “rethrows” keyword that adorns a
func decl, so it didn’t cause an extra level of indentation. A very common
case is, “I am not directly throwing any errors of my own; I promise to only
propagate errors thrown by my parameters (including generic parameters), and it
doesn’t matter which of them throws.”
> 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] <mailto:[email protected]>> wrote:
>>
>>>
>>> On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution
>>> <[email protected] <mailto:[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>
-Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
