From 162280b6d238ce32bbd8ff7a3f7992be82c2311a Mon Sep 17 00:00:00 2001 From: Ilya Kantor Date: Tue, 24 Mar 2020 05:49:21 +0300 Subject: [PATCH] minor fixes --- 1-js/10-error-handling/2-custom-errors/article.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1-js/10-error-handling/2-custom-errors/article.md b/1-js/10-error-handling/2-custom-errors/article.md index 2dfb8d6a..ff2e4c52 100644 --- a/1-js/10-error-handling/2-custom-errors/article.md +++ b/1-js/10-error-handling/2-custom-errors/article.md @@ -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". 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. -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`: