jeena/en.javascript.info
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

minor fixes

Browse source
This commit is contained in:
Ilya Kantor 2020-03-24 05:49:21 +03:00
parent fd81db7096
commit 162280b6d2
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
1-js/10-error-handling/2-custom-errors/article.md
View file

@ -244,10 +244,10 @@ Often the answer is "No": we'd like to be "one level above all that". We just wa
The technique that we describe here is called "wrapping exceptions". The technique that we describe here is called "wrapping exceptions".
1. We'll make a new class `ReadError` to represent a generic "data reading" error. 1. We'll make a new class `ReadError` to represent a generic "data reading" error.
2. The function `readUser` will catch data reading errors that occur inside it, such as `ValidationError` and `SyntaxError`, and generate `ReadError` instead. 2. The function `readUser` will catch data reading errors that occur inside it, such as `ValidationError` and `SyntaxError`, and generate a `ReadError` instead.
3. The `ReadError` object will keep the reference to the original error in its `cause` property. 3. The `ReadError` object will keep the reference to the original error in its `cause` property.
Then the code that calls `readUser` will only have to check for `ReadError`, not for every kind of data reading errors. Then the code that calls `readUser` will only have to check for `ReadError`, not for every kind of data reading errors. And if it needs more details of an error, it can check its `cause` property.
Here's the code that defines `ReadError` and demonstrates its use in `readUser` and `try..catch`: Here's the code that defines `ReadError` and demonstrates its use in `readUser` and `try..catch`: