-1. Doesn’t seem worthwhile. There aren’t that many use cases were your code
gets littered with try and it is nice to identify exactly what is throwing.
Sorry,
— Howard.
> On 4 Jan 2016, at 2:52 PM, Andrew Duncan via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On 3 Jan, 2016, at 10:51, David Waite <da...@alkaline-solutions.com> wrote:
>>
>> 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)
>> recognizeName()
>> recognizeFormalParamSeq()
>> accept(.newline)
>> recognizeCommandSeq()
>> accept(.end)
>> recognizeName()
>> accept(.newline)
>> }
>> }
>
> Not bad, modulo all the subsequent reasonable comments, of course.
>
> It is worth pointing out that (some would say) this is not error-handling at
> all. It’s a normal part of the recognizer life-cycle that it finds a syntax
> error in the source code. True, it is the (l)user’s error, but not mine.
> (Those have full-on asserts. Hey, could we have Eiffel-style contracts? Oops,
> new thread.)
>
> What I am after here is a quick-and-clean way to unwind the stack. My
> throwing recognizer has about 200 “try” statements in it. I tried (NPI) this
> both with exceptions and with Optional return values. Hard to say which I
> prefer. But is it not more or less the same underneath the hood? I gather
> that Swift adds an extra return value for throwing functions.
>
>
> _______________________________________________
> 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
