<div>Well, as Dave pointed, you can very rarely recover from an error, which IMO is absolutely true.</div><div><br></div><div>If your operation fails you don't really care unless you can recover. And you know your cases, which you can recover from (in reality one usually does it in optimization phase, though).</div><div><br></div><div>What else do you need the type of error for at the very end of your call stack? In 90% you will tell the user "ah, sorry, something happened. Come back later" and log the error (if you haven't forgot it).</div><div><br></div><div>In most cases the errors are not for recovering. They neither are to be presented to users. They are for developers to read the log/crash report/whatever else and analyze it. Most of the errors are for debugging purposes.</div><div><br></div><div>I don't want to deal with cumbersome code the purpose of which is to just "obey the language rules". Unless I know how to recover I would rethrow it. Than catch at the top of the stack and log + show the user a nice "sorry" message without getting techy.</div><div><br><div class="gmail_quote"><div>On Tue, 28 Feb 2017 at 1:12 Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Feb 27, 2017, at 5:01 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="gmail_msg" target="_blank">dabrahams@apple.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> on Mon Feb 27 2017, Matthew Johnson <matthew-AT-anandabits.com> wrote:<br class="gmail_msg">
><br class="gmail_msg">
>>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="gmail_msg" target="_blank">dabrahams@apple.com</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> I'm sorry, I don't see any substantive difference, based on what you've<br class="gmail_msg">
>>> written here, between this feature and const.<br class="gmail_msg">
>><br class="gmail_msg">
>> Let me give it one more shot and then I’ll drop it. :)<br class="gmail_msg">
>><br class="gmail_msg">
>> Const is viral because if an API does not declare its arguments const<br class="gmail_msg">
>> it cannot be used by a caller who has a const argument.<br class="gmail_msg">
><br class="gmail_msg">
> Unless the caller casts away const, thus erasing information that was<br class="gmail_msg">
> previously encoded in the type system.<br class="gmail_msg">
<br class="gmail_msg">
Yes, of course.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
>> It is required in order to make an API as generally useful as<br class="gmail_msg">
>> possible.<br class="gmail_msg">
>><br class="gmail_msg">
>> Typed errors are not viral in this way because no callers are<br class="gmail_msg">
>> prevented from calling an API regardless of whether it declares error<br class="gmail_msg">
>> types or just throws Error like we have today.<br class="gmail_msg">
><br class="gmail_msg">
> Unless the caller can recover (which is *very* rare) or it catches and<br class="gmail_msg">
> rethrows one of the errors *it* declares, thus erasing information that<br class="gmail_msg">
> was previously encoded in the type system.<br class="gmail_msg">
<br class="gmail_msg">
I view this as being fundamentally different than casting away const. Casting away const says “I know better than the types”.<br class="gmail_msg">
<br class="gmail_msg">
Converting an error to a different type is extremely different. It much more similar to any other kind of value wrapper a library might create in order to shield its users from being coupled to its implementation details / dependencies. This is not a way *around* the type system in the sense that casting away const is. It is a way of *using* the type system (hopefully) to your advantage.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
>> Pressure to declare error types in your signature in order to make<br class="gmail_msg">
>> your function as generally useful as possible does not exist. Each<br class="gmail_msg">
>> function is free to declare error types or not according to the<br class="gmail_msg">
>> contract it wishes to expose.<br class="gmail_msg">
>><br class="gmail_msg">
>> An argument can be made that community expectations might develop that<br class="gmail_msg">
>> good APIs should declare error types and they could be considered<br class="gmail_msg">
>> viral in this sense because any API that is simply declared `throws`<br class="gmail_msg">
>> is dropping type information. But I think this overstates the case.<br class="gmail_msg">
>> The community appears to be very sensitive to the problems that can<br class="gmail_msg">
>> arise when error types are too concrete, especially across module<br class="gmail_msg">
>> boundaries. I think we can learn to use the tool where it works well<br class="gmail_msg">
>> and to avoid it where it causes problems.<br class="gmail_msg">
>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> --<br class="gmail_msg">
>>> -Dave<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
> --<br class="gmail_msg">
> -Dave<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>