-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethrow exception in fail block #9
Comments
The So a single method that both transforms the success and failure values and returns a new Promise. |
I think its better to add |
I'm not convinced it should be added to the library. What are the arguments for adding this? Though it can easily be added to peoples own projects:
|
In Android world it is pretty common scenario, where you want to map some 3rd party library |
This is a huge limitation. All promise/task libraries we've worked with in the past allow manipulating the promise chain so that you can map errors (for example the Bolts library's continueWith(..) VS continueWithTask(..) – reference here https://github.com/BoltsFramework/Bolts-Android). This allows you to log error messages in your application services / business layer for example, and present any user UI in your presentation layer (Activities/Fragments). Mapping from 3rd-party exception types to custom exceptions as mentioned by @friendoye is also a core use case. This essentially means you cannot do any custom logic along the failure chain, only the success one (ie: with 'then'). Please, please, add these in. The library is otherwise so great, but cannot be deemed mature without such core functionality missing. Here's a real-world example: Presentation layer:
Application/business layer:
NOTE: Examples above use a convenience version of your method above which only has the failure mapping code included – since this can be a common scenario.
|
I would like to catch any
Exception
infail
block and then rethrow it asWrappedException
. Code should be look like that:But instead of providing
WrappedException
in sequentialfail
blocks, kovenant provides the same error. As I can see that's happening because lambdas, that are passed tofail
, are used as callbacks instead of something likemap
function.What are you thoughts on this problem and what can you suggest to overcome this problem?
The text was updated successfully, but these errors were encountered: