Handling Generic API Errors and Avoiding Breakage
Is there a good solution to this?
I’m wrapping an api that throws a very generic error. I’m creating types for them that are more specific and returning those when I can, falling back to the generic one. I publish a library as v1. Time goes on and I find another specific error type that is helpful to know about. So I add it to the union of possible error types.
How do I avoid breaking consumers of the library whose code handles that error case with the generic version of the error?
I’m wrapping an api that throws a very generic error. I’m creating types for them that are more specific and returning those when I can, falling back to the generic one. I publish a library as v1. Time goes on and I find another specific error type that is helpful to know about. So I add it to the union of possible error types.
How do I avoid breaking consumers of the library whose code handles that error case with the generic version of the error?
Production-grade applications in TypeScript.
6,221Members
Resources
Recent Announcements
Similar Threads
Was this page helpful?
