> On Feb 28, 2017, at 12:44 PM, Dave Abrahams <[email protected]> wrote: > > > on Tue Feb 28 2017, Karl Wagner <razielim-AT-gmail.com> wrote: > >>> On 28 Feb 2017, at 18:00, Matthew Johnson <[email protected]> wrote: >>> >>> >>>> On Feb 28, 2017, at 10:44 AM, Daniel Leping <[email protected] >> <mailto:[email protected]>> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
