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. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
