[swift-evolution] [Pitch] Typed throws
dabrahams at apple.com
Tue Feb 28 12:44:11 CST 2017
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
>> 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
but I think the most interesting discussion is probably in the foregoing
(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.
More information about the swift-evolution