[swift-evolution] [Pitch] Typed throws

[Matthew Johnson]

> On Feb 28, 2017, at 12:44 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Tue Feb 28 2017, Karl Wagner <razielim-AT-gmail.com> wrote:
> 
>>> On 28 Feb 2017, at 18:00, Matthew Johnson <matthew at anandabits.com> wrote:
>>> 
>>> 
>>>> On Feb 28, 2017, at 10:44 AM, Daniel Leping <daniel at crossroadlabs.xyz
>> <mailto:daniel at crossroadlabs.xyz>> wrote:
>>>> 
>> 
>>>> Mathew, I totally understand what you're talking about. And this is exactly what I want to avoid.
>>>> 
>>>> If a library developer knows how to handle certain case
>>>> (i.e. recover or throw a special error) I'm ok with it. Though I'm
>>>> not ok with completely hiding errors from the underlying
>>>> implementation. The library developer might not handle
>>>> EVERYTHING. I want to know what happened and where. Otherwise I
>>>> will have to explicitly debug his library to find out what the
>>>> issue is. In most cases I will not have time to wait developer
>>>> fixing the library. I will fix it myself and make PR. So I consider
>>>> tranparent errors rather a benefit.
>>>> 
>>>> Hiding errors under library errors might have worked for
>>>> proprietary middleware. Today the world changed. It's open source
>>>> now.
>>> 
>>> I agree with you that having *access* to the original error is
>>> important and that a library should not be expected to handle every
>>> case.  I hope I have not said anything that suggests otherwise.
>>> 
>>> What I’m suggesting is that if the error originated in a dependency
>>> that might change it should be wrapped in a stable abstraction that
>>> the users of the library can depend on.  The underlying error should
>>> still be available via a property or associated value exposed with
>>> an existential type.  If you expect users to catch errors thrown by
>>> a dependency that might change you have a fragile API contract in
>>> the area of errors.
>>> 
>>> This can easily lead to unreliable software - when you change the
>>> dependency nothing alerts users to the fact that their error
>>> handling code is probably broken.  Even if the compiler told them it
>>> was broken, they now have the burden of learning about the errors
>>> that might come from your new dependency.  An API that could lead to
>>> this consequence is badly designed IMO.
>>> 
>>> I even suggested adding a new requirement to `Error` that includes a
>>> default implementation to standardize how we access wrapped errors,
>>> including the originating error underneath all wrapper layers.
>>> 
>> 
>> I don’t see that it’s such a big problem. There are lots of ways to
>> expose the information once we have it, and it could easily be limited
>> to public errors from the current module (substituting private/unbound
>> errors with an erasing “Error”). There are lots of small improvements
>> we could make: such as having functions which re-throw errors from
>> other, manually documented functions inherit their documentation (or
>> at least appear to, when viewed). That would not be totally
>> compiler-generated documentation, but would mean you can document your
>> errors in one place and make doing so much more palatable. :
> 
> I just want to point at some prior art in this area,
> http://boost.org/libs/exception, which deals with the issues of wrapping
> errors at library boundaries and the dynamic construction of a stack of
> useful information.  This library was designed about 10 years ago, but I
> still remember the design discussions as compelling.  The formal review
> thread is here
> http://boost.2283326.n4.nabble.com/review-Review-of-Exception-begins-today-tt2633630.html#none
> but I think the most interesting discussion is probably in the foregoing
> thread
> http://boost.2283326.n4.nabble.com/Review-Request-Boost-Exception-tt2616607.html#a2616624
> (among which my comments are probably the *least* useful).
> 
> Anyone interested in pursuing features in this area should probably
> review those discussions.  Even though the context is C++, I think
> there's very little in it that's language-specific.

Thanks for the links Dave!  I will add this to my list of things to investigate further.

> 
> -- 
> -Dave