[swift-evolution] [Pitch] Typed throws

[Dave Abrahams]

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.

-- 
-Dave