> On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution
> <[email protected] <mailto:[email protected]>> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
