<div dir="ltr">On Sun, Jan 15, 2017 at 3:12 PM, Haravikk <span dir="ltr"><<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_3316592772594932485Apple-interchange-newline"><div><div dir="ltr">On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I really like swift’s error handling system overall. It strikes a good balance between safety and usability.<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div></div></div></div></div></blockquote><br></div></span><div>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.</div><div><br></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>`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).</div></div><br></div></div>