Consider you are developing a math library which has a function . isPi Now you are saying something like — We don’t want to care where do we take the data(db, network, etc). So, the function should receive a promise: and now we can use the function like this: cool, yep? No. You don’t “wrapping arbitrary user in Promise to don’t have to care if user’s code is synchronous or asynchronous”, but a promise is something which will be resolved with some data or rejected with some error at some moment code so, I can remove some code unnecessary You can ask: The problem appears when you add some error handling. You can easily finish with the code below: ok, the initial code is redundant, but why it’s bad? It’s wrong because implementation has too much knowledge about the source of a promise. The proper way to rewrite this code is something like this: isPi So, two rules of thumb here are: try to handle errors as “closer” as possible to their source separate async operations from sync. Treating everything as an async operation leads to coupled code. is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Facebook

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Unnecessary promise wrapping

Too Long; Didn't Read

Company Mentioned

Max Kharandziuk

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Unnecessary promise wrapping

Too Long; Didn't Read

Company Mentioned

Max Kharandziuk

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES