[swift-evolution] Throws? and throws!

[Xiaodi Wu]

On Sun, Jan 15, 2017 at 3:12 PM, Haravikk <swift-evolution at haravikk.me>
wrote:

>
> On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I really like swift’s error handling system overall. It strikes a good
>> balance between safety and usability.
>>
>> There are some cases where it would be nice to throw errors, but errors
>> are rarely expected in most use cases, so the overhead of ‘try’, etc… would
>> make things unusable. Thus fatalError or optionals are used instead.  For
>> example, operators like ‘+’ could never throw because adding ’try’
>> everywhere would make arithmetic unbearable. But in a few cases it would
>> make my algorithm much cleaner if I just assume it will work and then catch
>> overflow/underflow errors if they happen, and resolve each of them with
>> special cases.  Or perhaps I am dealing with user entered values, and want
>> to stop the calculation and display a user visible error (e.g. a symbol in
>> a spreadsheet cell) instead of crashing.
>>
>
> Unless I'm mistaken, there is a performance overhead for throwing
> functions, and thus a much greater barrier to the use cases outlined above
> is that the performance penalty for '+' would be unacceptable in any case,
> whatever syntactic sugar you could come up with.
>
>
> Just wanted to chime in on performance, but since operators should really
> be inlined in most cases anyway I'm not sure there should be any
> performance penalty; the compiler should just optimise it away such that it
> basically becomes what it is now, the only case in which it would add a
> penalty is if the optional try is actually used.
>
>
> I really like this idea personally; I prefer it to using the
> addWithOverflow() and similar methods, not that they're super burdensome,
> but error handling feels like a better fit IMO.
>

`addWithOverflow()` gives you both the result and a flag; error handling
would at most give you one of these two. If that's a common use case, it'd
be an argument for a failable addition operator, but not a throwing one,
since there is only one error that happens (overflow).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170115/809df1cf/attachment.html>