A tool to solve the problem of multiple ecmascript error possibilities. It will normalize in single error structure.
In addition to the issue of throwable structures, there are other error structures in ecmascript, in most cases, these others are related to the servers to which the application will connect. These defects can have different structures, here is a document where you can read some of the more common http problems.
A classe that's know how to convert all errors into a single structure, a normalized structure.
The Solution Implementation
The error converter is a structure that will centralize all solutions for all possibilities of errors in your software, and it can normalize then:
// normalization for simple error;;// normalization for http error;xhr.onreadystatechange =;
ErrorConverter will be every a singleton and all new instance will return the same instance. You can provide this class into your angular aplication, as a service, you must use a factory function for that.
But for the error converter know how to normalize, you must say to it using an adapter:
You will need to create adapters representing each of the possibilities of errors that may occur within your software, like this one:
/*** Implement the ICustomErrorAdapter interface.*/
For an XMLHttpRequest error, you will need to create the following signature:
The normalized interface
/*** This is a proposal for an normalized error*/
1. Create an issue
No one feature will be implemented without it having an open issue and without which the proposed has been accepted by the team responsible for the project. After the issue is approved, the applicant, a team member or anyone else can open a pull request associated with that issue (just paste the issue link in the pull request).
2. Did you find a bug?
When logging a bug, please be sure to include the following:
- The library version;
- If at all possible, an isolated way to reproduce the behavior;
- The behavior you expect to see, and the actual behavior.
You can try to update the library to the last version to see if the bug has already been fixed.
3. Do not create a duplicate issue
Search the existing issues before logging a new one.
Some search tips:
- Don't restrict your search to only open issues. An issue with a title similar to yours may have been closed as a duplicate of one with a less-findable title.
- Check for synonyms. For example, if your bug involves an interface, it likely also occurs with type aliases or classes.
4. Create a Pull Request
Follow the steps:
- Create a fork from our repository by clicking here, install node, do a
git cloneof your forked repository and run
npm installin the application folder;
- Create a branch in your forked repository, then code the feature or fix the bug;
npm run lint,
npm run testand
npm run buildin the repository;
- Create a Pull Request from your repository to this one, with the issue in the body and some information you think could be usefull to the reviewer (print or a gif of it working will be appreciated);
- The reviewer can ask some changes, don't be mad, this is the GIT Flow process;
- You get approved and your branch with the feature / fix