From bc20e273d5c3300e3e77c9838a2758f19b4e3068 Mon Sep 17 00:00:00 2001 From: Jared Collier Date: Tue, 9 Jul 2019 12:18:22 -0400 Subject: [PATCH] Update wording of one paragraph explainer. --- sections/errorhandling/useonlythebuiltinerror.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sections/errorhandling/useonlythebuiltinerror.md b/sections/errorhandling/useonlythebuiltinerror.md index 34a4ba59..3d83c6de 100644 --- a/sections/errorhandling/useonlythebuiltinerror.md +++ b/sections/errorhandling/useonlythebuiltinerror.md @@ -2,7 +2,7 @@ ### One Paragraph Explainer -The permissive nature of JavaScript along with its variety code-flow options (e.g. EventEmitter, Callbacks, Promises, etc) pushes to great variance in how developers raise errors – some use strings, other define their own custom types. Using Node.js built-in Error object helps to keep uniformity within your code and with 3rd party libraries, it also preserves significant information like the StackTrace. When raising the exception, it’s usually a good practice to fill it with additional contextual properties like the error name and the associated HTTP error code. To achieve this uniformity and practices, consider extending the Error object with additional properties, see code example below +The permissive nature of JavaScript along with its variety of code-flow options (e.g. EventEmitter, Callbacks, Promises, etc) pushes to great variance in how developers raise errors – some use strings, other define their own custom types. Using Node.js built-in Error object helps to keep uniformity within your code and with 3rd party libraries, it also preserves significant information like the StackTrace. When raising the exception, it’s usually a good practice to fill it with additional contextual properties like the error name and the associated HTTP error code. To achieve this uniformity and practices, consider extending the Error object with additional properties, see code example below ### Code Example – doing it right