Some of those issues can be solved through refactoring efforts and abstraction. JS lacks typed errors in the catch statement, and while it would be nice to catch specific error types, you can still do that in the catch statement.
As JS evolves, it takes well-worn paradigms that are present and oft used in strongly typed languages. This is often a breaking point for devs that may only be experienced with JS, and not have that wider exposure. JS is an expressive language, but to be that way, it compromises on some of the aspects that strongly typed languages have that are baked in.
I don't agree that catching an error and returning it as a var reference is useful, it's not particularly testable, and further abstracts the api logic from the developer.
You didn't include in your examples, one example where the api request throws an error. Looking at a stack trace, it's polluted with try/catch/throw.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some of those issues can be solved through refactoring efforts and abstraction. JS lacks typed errors in the catch statement, and while it would be nice to catch specific error types, you can still do that in the catch statement.
As JS evolves, it takes well-worn paradigms that are present and oft used in strongly typed languages. This is often a breaking point for devs that may only be experienced with JS, and not have that wider exposure. JS is an expressive language, but to be that way, it compromises on some of the aspects that strongly typed languages have that are baked in.
I don't agree that catching an error and returning it as a var reference is useful, it's not particularly testable, and further abstracts the api logic from the developer.
You didn't include in your examples, one example where the api request throws an error. Looking at a stack trace, it's polluted with try/catch/throw.