refactor classes, add private, minor fixes
This commit is contained in:
Ilya Kantor
parent
a0c07342ad
commit
1373f6158c
270 changed files with 1513 additions and 890 deletions
|
|
@ -0,0 +1,47 @@
|
|||
The difference becomes obvious when we look at the code inside a function.
|
||||
|
||||
The behavior is different if there's a "jump out" of `try..catch`.
|
||||
|
||||
For instance, when there's a `return` inside `try..catch`. The `finally` clause works in case of *any* exit from `try..catch`, even via the `return` statement: right after `try..catch` is done, but before the calling code gets the control.
|
||||
|
||||
```js run
|
||||
function f() {
|
||||
try {
|
||||
alert('start');
|
||||
*!*
|
||||
return "result";
|
||||
*/!*
|
||||
} catch (e) {
|
||||
/// ...
|
||||
} finally {
|
||||
alert('cleanup!');
|
||||
}
|
||||
}
|
||||
|
||||
f(); // cleanup!
|
||||
```
|
||||
|
||||
...Or when there's a `throw`, like here:
|
||||
|
||||
```js run
|
||||
function f() {
|
||||
try {
|
||||
alert('start');
|
||||
throw new Error("an error");
|
||||
} catch (e) {
|
||||
// ...
|
||||
if("can't handle the error") {
|
||||
*!*
|
||||
throw e;
|
||||
*/!*
|
||||
}
|
||||
|
||||
} finally {
|
||||
alert('cleanup!')
|
||||
}
|
||||
}
|
||||
|
||||
f(); // cleanup!
|
||||
```
|
||||
|
||||
It's `finally` that guarantees the cleanup here. If we just put the code at the end of `f`, it wouldn't run.
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
importance: 5
|
||||
|
||||
---
|
||||
|
||||
# Finally or just the code?
|
||||
|
||||
Compare the two code fragments.
|
||||
|
||||
1. The first one uses `finally` to execute the code after `try..catch`:
|
||||
|
||||
```js
|
||||
try {
|
||||
work work
|
||||
} catch (e) {
|
||||
handle errors
|
||||
} finally {
|
||||
*!*
|
||||
cleanup the working space
|
||||
*/!*
|
||||
}
|
||||
```
|
||||
2. The second fragment puts the cleaning right after `try..catch`:
|
||||
|
||||
```js
|
||||
try {
|
||||
work work
|
||||
} catch (e) {
|
||||
handle errors
|
||||
}
|
||||
|
||||
*!*
|
||||
cleanup the working space
|
||||
*/!*
|
||||
```
|
||||
|
||||
We definitely need the cleanup after the work has started, doesn't matter if there was an error or not.
|
||||
|
||||
Is there an advantage here in using `finally` or both code fragments are equal? If there is such an advantage, then give an example when it matters.
|
||||
675
1-js/10-error-handling/1-try-catch/article.md
Normal file
675
1-js/10-error-handling/1-try-catch/article.md
Normal file
|
|
@ -0,0 +1,675 @@
|
|||
# Error handling, "try..catch"
|
||||
|
||||
No matter how great we are at programming, sometimes our scripts have errors. They may occur because of our mistakes, an unexpected user input, an erroneous server response and for a thousand of other reasons.
|
||||
|
||||
Usually, a script "dies" (immediately stops) in case of an error, printing it to console.
|
||||
|
||||
But there's a syntax construct `try..catch` that allows to "catch" errors and, instead of dying, do something more reasonable.
|
||||
|
||||
## The "try..catch" syntax
|
||||
|
||||
The `try..catch` construct has two main blocks: `try`, and then `catch`:
|
||||
|
||||
```js
|
||||
try {
|
||||
|
||||
// code...
|
||||
|
||||
} catch (err)] {
|
||||
|
||||
// error handling
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
It works like this:
|
||||
|
||||
1. First, the code in `try {...}` is executed.
|
||||
2. If there were no errors, then `catch(err)` is ignored: the execution reaches the end of `try` and then jumps over `catch`.
|
||||
3. If an error occurs, then `try` execution is stopped, and the control flows to the beginning of `catch(err)`. The `err` variable (can use any name for it) contains an error object with details about what's happened.
|
||||
|
||||
|
||||
|
||||
So, an error inside the `try {…}` block does not kill the script: we have a chance to handle it in `catch`.
|
||||
|
||||
Let's see more examples.
|
||||
|
||||
- An errorless example: shows `alert` `(1)` and `(2)`:
|
||||
|
||||
```js run
|
||||
try {
|
||||
|
||||
alert('Start of try runs'); // *!*(1) <--*/!*
|
||||
|
||||
// ...no errors here
|
||||
|
||||
alert('End of try runs'); // *!*(2) <--*/!*
|
||||
|
||||
} catch(err) {
|
||||
|
||||
alert('Catch is ignored, because there are no errors'); // (3)
|
||||
|
||||
}
|
||||
|
||||
alert("...Then the execution continues");
|
||||
```
|
||||
- An example with an error: shows `(1)` and `(3)`:
|
||||
|
||||
```js run
|
||||
try {
|
||||
|
||||
alert('Start of try runs'); // *!*(1) <--*/!*
|
||||
|
||||
*!*
|
||||
lalala; // error, variable is not defined!
|
||||
*/!*
|
||||
|
||||
alert('End of try (never reached)'); // (2)
|
||||
|
||||
} catch(err) {
|
||||
|
||||
alert(`Error has occured!`); // *!*(3) <--*/!*
|
||||
|
||||
}
|
||||
|
||||
alert("...Then the execution continues");
|
||||
```
|
||||
|
||||
|
||||
````warn header="`try..catch` only works for runtime errors"
|
||||
For `try..catch` to work, the code must be runnable. In other words, it should be valid JavaScript.
|
||||
|
||||
It won't work if the code is syntactically wrong, for instance it has unmatched curly braces:
|
||||
|
||||
```js run
|
||||
try {
|
||||
{{{{{{{{{{{{
|
||||
} catch(e) {
|
||||
alert("The engine can't understand this code, it's invalid");
|
||||
}
|
||||
```
|
||||
|
||||
The JavaScript engine first reads the code, and then runs it. The errors that occur on the reading phrase are called "parse-time" errors and are unrecoverable (from inside that code). That's because the engine can't understand the code.
|
||||
|
||||
So, `try..catch` can only handle errors that occur in the valid code. Such errors are called "runtime errors" or, sometimes, "exceptions".
|
||||
````
|
||||
|
||||
|
||||
````warn header="`try..catch` works synchronously"
|
||||
If an exception happens in "scheduled" code, like in `setTimeout`, then `try..catch` won't catch it:
|
||||
|
||||
```js run
|
||||
try {
|
||||
setTimeout(function() {
|
||||
noSuchVariable; // script will die here
|
||||
}, 1000);
|
||||
} catch (e) {
|
||||
alert( "won't work" );
|
||||
}
|
||||
```
|
||||
|
||||
That's because `try..catch` actually wraps the `setTimeout` call that schedules the function. But the function itself is executed later, when the engine has already left the `try..catch` construct.
|
||||
|
||||
To catch an exception inside a scheduled function, `try..catch` must be inside that function:
|
||||
```js run
|
||||
setTimeout(function() {
|
||||
try {
|
||||
noSuchVariable; // try..catch handles the error!
|
||||
} catch {
|
||||
alert( "error is caught here!" );
|
||||
}
|
||||
}, 1000);
|
||||
```
|
||||
````
|
||||
|
||||
## Error object
|
||||
|
||||
When an error occurs, JavaScript generates an object containing the details about it. The object is then passed as an argument to `catch`:
|
||||
|
||||
```js
|
||||
try {
|
||||
// ...
|
||||
} catch(err) { // <-- the "error object", could use another word instead of err
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
For all built-in errors, the error object inside `catch` block has two main properties:
|
||||
|
||||
`name`
|
||||
: Error name. For an undefined variable that's `"ReferenceError"`.
|
||||
|
||||
`message`
|
||||
: Textual message about error details.
|
||||
|
||||
There are other non-standard properties available in most environments. One of most widely used and supported is:
|
||||
|
||||
`stack`
|
||||
: Current call stack: a string with information about the sequence of nested calls that led to the error. Used for debugging purposes.
|
||||
|
||||
For instance:
|
||||
|
||||
```js run untrusted
|
||||
try {
|
||||
*!*
|
||||
lalala; // error, variable is not defined!
|
||||
*/!*
|
||||
} catch(err) {
|
||||
alert(err.name); // ReferenceError
|
||||
alert(err.message); // lalala is not defined
|
||||
alert(err.stack); // ReferenceError: lalala is not defined at ...
|
||||
|
||||
// Can also show an error as a whole
|
||||
// The error is converted to string as "name: message"
|
||||
alert(err); // ReferenceError: lalala is not defined
|
||||
}
|
||||
```
|
||||
|
||||
## Optional "catch" binding
|
||||
|
||||
[recent browser=new]
|
||||
|
||||
If we don't need error details, `catch` may omit it:
|
||||
|
||||
```js
|
||||
try {
|
||||
// ...
|
||||
} catch {
|
||||
// error object omitted
|
||||
}
|
||||
```
|
||||
|
||||
## Using "try..catch"
|
||||
|
||||
Let's explore a real-life use case of `try..catch`.
|
||||
|
||||
As we already know, JavaScript supports the [JSON.parse(str)](mdn:js/JSON/parse) method to read JSON-encoded values.
|
||||
|
||||
Usually it's used to decode data received over the network, from the server or another source.
|
||||
|
||||
We receive it and call `JSON.parse`, like this:
|
||||
|
||||
```js run
|
||||
let json = '{"name":"John", "age": 30}'; // data from the server
|
||||
|
||||
*!*
|
||||
let user = JSON.parse(json); // convert the text representation to JS object
|
||||
*/!*
|
||||
|
||||
// now user is an object with properties from the string
|
||||
alert( user.name ); // John
|
||||
alert( user.age ); // 30
|
||||
```
|
||||
|
||||
You can find more detailed information about JSON in the <info:json> chapter.
|
||||
|
||||
**If `json` is malformed, `JSON.parse` generates an error, so the script "dies".**
|
||||
|
||||
Should we be satisfied with that? Of course, not!
|
||||
|
||||
This way, if something's wrong with the data, the visitor will never know that (unless they open the developer console). And people really don't like when something "just dies" without any error message.
|
||||
|
||||
Let's use `try..catch` to handle the error:
|
||||
|
||||
```js run
|
||||
let json = "{ bad json }";
|
||||
|
||||
try {
|
||||
|
||||
*!*
|
||||
let user = JSON.parse(json); // <-- when an error occurs...
|
||||
*/!*
|
||||
alert( user.name ); // doesn't work
|
||||
|
||||
} catch (e) {
|
||||
*!*
|
||||
// ...the execution jumps here
|
||||
alert( "Our apologies, the data has errors, we'll try to request it one more time." );
|
||||
alert( e.name );
|
||||
alert( e.message );
|
||||
*/!*
|
||||
}
|
||||
```
|
||||
|
||||
Here we use the `catch` block only to show the message, but we can do much more: send a new network request, suggest an alternative to the visitor, send information about the error to a logging facility, ... . All much better than just dying.
|
||||
|
||||
## Throwing our own errors
|
||||
|
||||
What if `json` is syntactically correct, but doesn't have a required `name` property?
|
||||
|
||||
Like this:
|
||||
|
||||
```js run
|
||||
let json = '{ "age": 30 }'; // incomplete data
|
||||
|
||||
try {
|
||||
|
||||
let user = JSON.parse(json); // <-- no errors
|
||||
*!*
|
||||
alert( user.name ); // no name!
|
||||
*/!*
|
||||
|
||||
} catch (e) {
|
||||
alert( "doesn't execute" );
|
||||
}
|
||||
```
|
||||
|
||||
Here `JSON.parse` runs normally, but the absence of `name` is actually an error for us.
|
||||
|
||||
To unify error handling, we'll use the `throw` operator.
|
||||
|
||||
### "Throw" operator
|
||||
|
||||
The `throw` operator generates an error.
|
||||
|
||||
The syntax is:
|
||||
|
||||
```js
|
||||
throw <error object>
|
||||
```
|
||||
|
||||
Technically, we can use anything as an error object. That may be even a primitive, like a number or a string, but it's better to use objects, preferably with `name` and `message` properties (to stay somewhat compatible with built-in errors).
|
||||
|
||||
JavaScript has many built-in constructors for standard errors: `Error`, `SyntaxError`, `ReferenceError`, `TypeError` and others. We can use them to create error objects as well.
|
||||
|
||||
Their syntax is:
|
||||
|
||||
```js
|
||||
let error = new Error(message);
|
||||
// or
|
||||
let error = new SyntaxError(message);
|
||||
let error = new ReferenceError(message);
|
||||
// ...
|
||||
```
|
||||
|
||||
For built-in errors (not for any objects, just for errors), the `name` property is exactly the name of the constructor. And `message` is taken from the argument.
|
||||
|
||||
For instance:
|
||||
|
||||
```js run
|
||||
let error = new Error("Things happen o_O");
|
||||
|
||||
alert(error.name); // Error
|
||||
alert(error.message); // Things happen o_O
|
||||
```
|
||||
|
||||
Let's see what kind of error `JSON.parse` generates:
|
||||
|
||||
```js run
|
||||
try {
|
||||
JSON.parse("{ bad json o_O }");
|
||||
} catch(e) {
|
||||
*!*
|
||||
alert(e.name); // SyntaxError
|
||||
*/!*
|
||||
alert(e.message); // Unexpected token o in JSON at position 0
|
||||
}
|
||||
```
|
||||
|
||||
As we can see, that's a `SyntaxError`.
|
||||
|
||||
And in our case, the absence of `name` could be treated as a syntax error also, assuming that users must have a `name`.
|
||||
|
||||
So let's throw it:
|
||||
|
||||
```js run
|
||||
let json = '{ "age": 30 }'; // incomplete data
|
||||
|
||||
try {
|
||||
|
||||
let user = JSON.parse(json); // <-- no errors
|
||||
|
||||
if (!user.name) {
|
||||
*!*
|
||||
throw new SyntaxError("Incomplete data: no name"); // (*)
|
||||
*/!*
|
||||
}
|
||||
|
||||
alert( user.name );
|
||||
|
||||
} catch(e) {
|
||||
alert( "JSON Error: " + e.message ); // JSON Error: Incomplete data: no name
|
||||
}
|
||||
```
|
||||
|
||||
In the line `(*)`, the `throw` operator generates a `SyntaxError` with the given `message`, the same way as JavaScript would generate it itself. The execution of `try` immediately stops and the control flow jumps into `catch`.
|
||||
|
||||
Now `catch` became a single place for all error handling: both for `JSON.parse` and other cases.
|
||||
|
||||
## Rethrowing
|
||||
|
||||
In the example above we use `try..catch` to handle incorrect data. But is it possible that *another unexpected error* occurs within the `try {...}` block? Like a variable is undefined or something else, not just that "incorrect data" thing.
|
||||
|
||||
Like this:
|
||||
|
||||
```js run
|
||||
let json = '{ "age": 30 }'; // incomplete data
|
||||
|
||||
try {
|
||||
user = JSON.parse(json); // <-- forgot to put "let" before user
|
||||
|
||||
// ...
|
||||
} catch(err) {
|
||||
alert("JSON Error: " + err); // JSON Error: ReferenceError: user is not defined
|
||||
// (no JSON Error actually)
|
||||
}
|
||||
```
|
||||
|
||||
Of course, everything's possible! Programmers do make mistakes. Even in open-source utilities used by millions for decades -- suddenly a crazy bug may be discovered that leads to terrible hacks (like it happened with the `ssh` tool).
|
||||
|
||||
In our case, `try..catch` is meant to catch "incorrect data" errors. But by its nature, `catch` gets *all* errors from `try`. Here it gets an unexpected error, but still shows the same `"JSON Error"` message. That's wrong and also makes the code more difficult to debug.
|
||||
|
||||
Fortunately, we can find out which error we get, for instance from its `name`:
|
||||
|
||||
```js run
|
||||
try {
|
||||
user = { /*...*/ };
|
||||
} catch(e) {
|
||||
*!*
|
||||
alert(e.name); // "ReferenceError" for accessing an undefined variable
|
||||
*/!*
|
||||
}
|
||||
```
|
||||
|
||||
The rule is simple:
|
||||
|
||||
**Catch should only process errors that it knows and "rethrow" all others.**
|
||||
|
||||
The "rethrowing" technique can be explained in more detail as:
|
||||
|
||||
1. Catch gets all errors.
|
||||
2. In `catch(err) {...}` block we analyze the error object `err`.
|
||||
2. If we don't know how to handle it, then we do `throw err`.
|
||||
|
||||
In the code below, we use rethrowing so that `catch` only handles `SyntaxError`:
|
||||
|
||||
```js run
|
||||
let json = '{ "age": 30 }'; // incomplete data
|
||||
try {
|
||||
|
||||
let user = JSON.parse(json);
|
||||
|
||||
if (!user.name) {
|
||||
throw new SyntaxError("Incomplete data: no name");
|
||||
}
|
||||
|
||||
*!*
|
||||
blabla(); // unexpected error
|
||||
*/!*
|
||||
|
||||
alert( user.name );
|
||||
|
||||
} catch(e) {
|
||||
|
||||
*!*
|
||||
if (e.name == "SyntaxError") {
|
||||
alert( "JSON Error: " + e.message );
|
||||
} else {
|
||||
throw e; // rethrow (*)
|
||||
}
|
||||
*/!*
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
The error throwing on line `(*)` from inside `catch` block "falls out" of `try..catch` and can be either caught by an outer `try..catch` construct (if it exists), or it kills the script.
|
||||
|
||||
So the `catch` block actually handles only errors that it knows how to deal with and "skips" all others.
|
||||
|
||||
The example below demonstrates how such errors can be caught by one more level of `try..catch`:
|
||||
|
||||
```js run
|
||||
function readData() {
|
||||
let json = '{ "age": 30 }';
|
||||
|
||||
try {
|
||||
// ...
|
||||
*!*
|
||||
blabla(); // error!
|
||||
*/!*
|
||||
} catch (e) {
|
||||
// ...
|
||||
if (e.name != 'SyntaxError') {
|
||||
*!*
|
||||
throw e; // rethrow (don't know how to deal with it)
|
||||
*/!*
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
try {
|
||||
readData();
|
||||
} catch (e) {
|
||||
*!*
|
||||
alert( "External catch got: " + e ); // caught it!
|
||||
*/!*
|
||||
}
|
||||
```
|
||||
|
||||
Here `readData` only knows how to handle `SyntaxError`, while the outer `try..catch` knows how to handle everything.
|
||||
|
||||
## try..catch..finally
|
||||
|
||||
Wait, that's not all.
|
||||
|
||||
The `try..catch` construct may have one more code clause: `finally`.
|
||||
|
||||
If it exists, it runs in all cases:
|
||||
|
||||
- after `try`, if there were no errors,
|
||||
- after `catch`, if there were errors.
|
||||
|
||||
The extended syntax looks like this:
|
||||
|
||||
```js
|
||||
*!*try*/!* {
|
||||
... try to execute the code ...
|
||||
} *!*catch*/!*(e) {
|
||||
... handle errors ...
|
||||
} *!*finally*/!* {
|
||||
... execute always ...
|
||||
}
|
||||
```
|
||||
|
||||
Try running this code:
|
||||
|
||||
```js run
|
||||
try {
|
||||
alert( 'try' );
|
||||
if (confirm('Make an error?')) BAD_CODE();
|
||||
} catch (e) {
|
||||
alert( 'catch' );
|
||||
} finally {
|
||||
alert( 'finally' );
|
||||
}
|
||||
```
|
||||
|
||||
The code has two ways of execution:
|
||||
|
||||
1. If you answer "Yes" to "Make an error?", then `try -> catch -> finally`.
|
||||
2. If you say "No", then `try -> finally`.
|
||||
|
||||
The `finally` clause is often used when we start doing something before `try..catch` and want to finalize it in any case of outcome.
|
||||
|
||||
For instance, we want to measure the time that a Fibonacci numbers function `fib(n)` takes. Naturally, we can start measuring before it runs and finish afterwards. But what if there's an error during the function call? In particular, the implementation of `fib(n)` in the code below returns an error for negative or non-integer numbers.
|
||||
|
||||
The `finally` clause is a great place to finish the measurements no matter what.
|
||||
|
||||
Here `finally` guarantees that the time will be measured correctly in both situations -- in case of a successful execution of `fib` and in case of an error in it:
|
||||
|
||||
```js run
|
||||
let num = +prompt("Enter a positive integer number?", 35)
|
||||
|
||||
let diff, result;
|
||||
|
||||
function fib(n) {
|
||||
if (n < 0 || Math.trunc(n) != n) {
|
||||
throw new Error("Must not be negative, and also an integer.");
|
||||
}
|
||||
return n <= 1 ? n : fib(n - 1) + fib(n - 2);
|
||||
}
|
||||
|
||||
let start = Date.now();
|
||||
|
||||
try {
|
||||
result = fib(num);
|
||||
} catch (e) {
|
||||
result = 0;
|
||||
*!*
|
||||
} finally {
|
||||
diff = Date.now() - start;
|
||||
}
|
||||
*/!*
|
||||
|
||||
alert(result || "error occured");
|
||||
|
||||
alert( `execution took ${diff}ms` );
|
||||
```
|
||||
|
||||
You can check by running the code with entering `35` into `prompt` -- it executes normally, `finally` after `try`. And then enter `-1` -- there will be an immediate error, an the execution will take `0ms`. Both measurements are done correctly.
|
||||
|
||||
In other words, there may be two ways to exit a function: either a `return` or `throw`. The `finally` clause handles them both.
|
||||
|
||||
|
||||
```smart header="Variables are local inside `try..catch..finally`"
|
||||
Please note that `result` and `diff` variables in the code above are declared *before* `try..catch`.
|
||||
|
||||
Otherwise, if `let` were made inside the `{...}` block, it would only be visible inside of it.
|
||||
```
|
||||
|
||||
````smart header="`finally` and `return`"
|
||||
The `finally` clause works for *any* exit from `try..catch`. That includes an explicit `return`.
|
||||
|
||||
In the example below, there's a `return` in `try`. In this case, `finally` is executed just before the control returns to the outer code.
|
||||
|
||||
```js run
|
||||
function func() {
|
||||
|
||||
try {
|
||||
*!*
|
||||
return 1;
|
||||
*/!*
|
||||
|
||||
} catch (e) {
|
||||
/* ... */
|
||||
} finally {
|
||||
*!*
|
||||
alert( 'finally' );
|
||||
*/!*
|
||||
}
|
||||
}
|
||||
|
||||
alert( func() ); // first works alert from finally, and then this one
|
||||
```
|
||||
````
|
||||
|
||||
````smart header="`try..finally`"
|
||||
|
||||
The `try..finally` construct, without `catch` clause, is also useful. We apply it when we don't want to handle errors right here, but want to be sure that processes that we started are finalized.
|
||||
|
||||
```js
|
||||
function func() {
|
||||
// start doing something that needs completion (like measurements)
|
||||
try {
|
||||
// ...
|
||||
} finally {
|
||||
// complete that thing even if all dies
|
||||
}
|
||||
}
|
||||
```
|
||||
In the code above, an error inside `try` always falls out, because there's no `catch`. But `finally` works before the execution flow jumps outside.
|
||||
````
|
||||
|
||||
## Global catch
|
||||
|
||||
```warn header="Environment-specific"
|
||||
The information from this section is not a part of the core JavaScript.
|
||||
```
|
||||
|
||||
Let's imagine we've got a fatal error outside of `try..catch`, and the script died. Like a programming error or something else terrible.
|
||||
|
||||
Is there a way to react on such occurrences? We may want to log the error, show something to the user (normally they don't see error messages) etc.
|
||||
|
||||
There is none in the specification, but environments usually provide it, because it's really useful. For instance, Node.JS has [process.on('uncaughtException')](https://nodejs.org/api/process.html#process_event_uncaughtexception) for that. And in the browser we can assign a function to special [window.onerror](mdn:api/GlobalEventHandlers/onerror) property. It will run in case of an uncaught error.
|
||||
|
||||
The syntax:
|
||||
|
||||
```js
|
||||
window.onerror = function(message, url, line, col, error) {
|
||||
// ...
|
||||
};
|
||||
```
|
||||
|
||||
`message`
|
||||
: Error message.
|
||||
|
||||
`url`
|
||||
: URL of the script where error happened.
|
||||
|
||||
`line`, `col`
|
||||
: Line and column numbers where error happened.
|
||||
|
||||
`error`
|
||||
: Error object.
|
||||
|
||||
For instance:
|
||||
|
||||
```html run untrusted refresh height=1
|
||||
<script>
|
||||
*!*
|
||||
window.onerror = function(message, url, line, col, error) {
|
||||
alert(`${message}\n At ${line}:${col} of ${url}`);
|
||||
};
|
||||
*/!*
|
||||
|
||||
function readData() {
|
||||
badFunc(); // Whoops, something went wrong!
|
||||
}
|
||||
|
||||
readData();
|
||||
</script>
|
||||
```
|
||||
|
||||
The role of the global handler `window.onerror` is usually not to recover the script execution -- that's probably impossible in case of programming errors, but to send the error message to developers.
|
||||
|
||||
There are also web-services that provide error-logging for such cases, like <https://errorception.com> or <http://www.muscula.com>.
|
||||
|
||||
They work like this:
|
||||
|
||||
1. We register at the service and get a piece of JS (or a script URL) from them to insert on pages.
|
||||
2. That JS script has a custom `window.onerror` function.
|
||||
3. When an error occurs, it sends a network request about it to the service.
|
||||
4. We can log in to the service web interface and see errors.
|
||||
|
||||
## Summary
|
||||
|
||||
The `try..catch` construct allows to handle runtime errors. It literally allows to try running the code and catch errors that may occur in it.
|
||||
|
||||
The syntax is:
|
||||
|
||||
```js
|
||||
try {
|
||||
// run this code
|
||||
} catch(err) {
|
||||
// if an error happened, then jump here
|
||||
// err is the error object
|
||||
} finally {
|
||||
// do in any case after try/catch
|
||||
}
|
||||
```
|
||||
|
||||
There may be no `catch` section or no `finally`, so `try..catch` and `try..finally` are also valid.
|
||||
|
||||
Error objects have following properties:
|
||||
|
||||
- `message` -- the human-readable error message.
|
||||
- `name` -- the string with error name (error constructor name).
|
||||
- `stack` (non-standard) -- the stack at the moment of error creation.
|
||||
|
||||
If error is not needed, we can omit it by using `catch {` instead of `catch(err) {`.
|
||||
|
||||
We can also generate our own errors using the `throw` operator. Technically, the argument of `throw` can be anything, but usually it's an error object inheriting from the built-in `Error` class. More on extending errors in the next chapter.
|
||||
|
||||
Rethrowing is a basic pattern of error handling: a `catch` block usually expects and knows how to handle the particular error type, so it should rethrow errors it doesn't know.
|
||||
|
||||
Even if we don't have `try..catch`, most environments allow to setup a "global" error handler to catch errors that "fall out". In-browser that's `window.onerror`.
|
||||
BIN
1-js/10-error-handling/1-try-catch/try-catch-flow.png
Normal file
BIN
1-js/10-error-handling/1-try-catch/try-catch-flow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
1-js/10-error-handling/1-try-catch/try-catch-flow@2x.png
Normal file
BIN
1-js/10-error-handling/1-try-catch/try-catch-flow@2x.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
|
|
@ -0,0 +1,16 @@
|
|||
```js run untrusted
|
||||
class FormatError extends SyntaxError {
|
||||
constructor(message) {
|
||||
super(message);
|
||||
this.name = "FormatError";
|
||||
}
|
||||
}
|
||||
|
||||
let err = new FormatError("formatting error");
|
||||
|
||||
alert( err.message ); // formatting error
|
||||
alert( err.name ); // FormatError
|
||||
alert( err.stack ); // stack
|
||||
|
||||
alert( err instanceof SyntaxError ); // true
|
||||
```
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
importance: 5
|
||||
|
||||
---
|
||||
|
||||
# Inherit from SyntaxError
|
||||
|
||||
Create a class `FormatError` that inherits from the built-in `SyntaxError` class.
|
||||
|
||||
It should support `message`, `name` and `stack` properties.
|
||||
|
||||
Usage example:
|
||||
|
||||
```js
|
||||
let err = new FormatError("formatting error");
|
||||
|
||||
alert( err.message ); // formatting error
|
||||
alert( err.name ); // FormatError
|
||||
alert( err.stack ); // stack
|
||||
|
||||
alert( err instanceof FormatError ); // true
|
||||
alert( err instanceof SyntaxError ); // true (because inherits from SyntaxError)
|
||||
```
|
||||
307
1-js/10-error-handling/2-custom-errors/article.md
Normal file
307
1-js/10-error-handling/2-custom-errors/article.md
Normal file
|
|
@ -0,0 +1,307 @@
|
|||
# Custom errors, extending Error
|
||||
|
||||
When we develop something, we often need our own error classes to reflect specific things that may go wrong in our tasks. For errors in network operations we may need `HttpError`, for database operations `DbError`, for searching operations `NotFoundError` and so on.
|
||||
|
||||
Our errors should support basic error properties like `message`, `name` and, preferably, `stack`. But they also may have other properties of their own, e.g. `HttpError` objects may have `statusCode` property with a value like `404` or `403` or `500`.
|
||||
|
||||
JavaScript allows to use `throw` with any argument, so technically our custom error classes don't need to inherit from `Error`. But if we inherit, then it becomes possible to use `obj instanceof Error` to identify error objects. So it's better to inherit from it.
|
||||
|
||||
As we build our application, our own errors naturally form a hierarchy, for instance `HttpTimeoutError` may inherit from `HttpError`, and so on.
|
||||
|
||||
## Extending Error
|
||||
|
||||
As an example, let's consider a function `readUser(json)` that should read JSON with user data.
|
||||
|
||||
Here's an example of how a valid `json` may look:
|
||||
```js
|
||||
let json = `{ "name": "John", "age": 30 }`;
|
||||
```
|
||||
|
||||
Internally, we'll use `JSON.parse`. If it receives malformed `json`, then it throws `SyntaxError`.
|
||||
|
||||
But even if `json` is syntactically correct, that doesn't mean that it's a valid user, right? It may miss the necessary data. For instance, it may not have `name` and `age` properties that are essential for our users.
|
||||
|
||||
Our function `readUser(json)` will not only read JSON, but check ("validate") the data. If there are no required fields, or the format is wrong, then that's an error. And that's not a `SyntaxError`, because the data is syntactically correct, but another kind of error. We'll call it `ValidationError` and create a class for it. An error of that kind should also carry the information about the offending field.
|
||||
|
||||
Our `ValidationError` class should inherit from the built-in `Error` class.
|
||||
|
||||
That class is built-in, but we should have its approximate code before our eyes, to understand what we're extending.
|
||||
|
||||
So here you are:
|
||||
|
||||
```js
|
||||
// The "pseudocode" for the built-in Error class defined by JavaScript itself
|
||||
class Error {
|
||||
constructor(message) {
|
||||
this.message = message;
|
||||
this.name = "Error"; // (different names for different built-in error classes)
|
||||
this.stack = <nested calls>; // non-standard, but most environments support it
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now let's go on and inherit `ValidationError` from it:
|
||||
|
||||
```js run untrusted
|
||||
*!*
|
||||
class ValidationError extends Error {
|
||||
*/!*
|
||||
constructor(message) {
|
||||
super(message); // (1)
|
||||
this.name = "ValidationError"; // (2)
|
||||
}
|
||||
}
|
||||
|
||||
function test() {
|
||||
throw new ValidationError("Whoops!");
|
||||
}
|
||||
|
||||
try {
|
||||
test();
|
||||
} catch(err) {
|
||||
alert(err.message); // Whoops!
|
||||
alert(err.name); // ValidationError
|
||||
alert(err.stack); // a list of nested calls with line numbers for each
|
||||
}
|
||||
```
|
||||
|
||||
Please take a look at the constructor:
|
||||
|
||||
1. In the line `(1)` we call the parent constructor. JavaScript requires us to call `super` in the child constructor, so that's obligatory. The parent constructor sets the `message` property.
|
||||
2. The parent constructor also sets the `name` property to `"Error"`, so in the line `(2)` we reset it to the right value.
|
||||
|
||||
Let's try to use it in `readUser(json)`:
|
||||
|
||||
```js run
|
||||
class ValidationError extends Error {
|
||||
constructor(message) {
|
||||
super(message);
|
||||
this.name = "ValidationError";
|
||||
}
|
||||
}
|
||||
|
||||
// Usage
|
||||
function readUser(json) {
|
||||
let user = JSON.parse(json);
|
||||
|
||||
if (!user.age) {
|
||||
throw new ValidationError("No field: age");
|
||||
}
|
||||
if (!user.name) {
|
||||
throw new ValidationError("No field: name");
|
||||
}
|
||||
|
||||
return user;
|
||||
}
|
||||
|
||||
// Working example with try..catch
|
||||
|
||||
try {
|
||||
let user = readUser('{ "age": 25 }');
|
||||
} catch (err) {
|
||||
if (err instanceof ValidationError) {
|
||||
*!*
|
||||
alert("Invalid data: " + err.message); // Invalid data: No field: name
|
||||
*/!*
|
||||
} else if (err instanceof SyntaxError) { // (*)
|
||||
alert("JSON Syntax Error: " + err.message);
|
||||
} else {
|
||||
throw err; // unknown error, rethrow it (**)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The `try..catch` block in the code above handles both our `ValidationError` and the built-in `SyntaxError` from `JSON.parse`.
|
||||
|
||||
Please take a look at how we use `instanceof` to check for the specific error type in the line `(*)`.
|
||||
|
||||
We could also look at `err.name`, like this:
|
||||
|
||||
```js
|
||||
// ...
|
||||
// instead of (err instanceof SyntaxError)
|
||||
} else if (err.name == "SyntaxError") { // (*)
|
||||
// ...
|
||||
```
|
||||
|
||||
The `instanceof` version is much better, because in the future we are going to extend `ValidationError`, make subtypes of it, like `PropertyRequiredError`. And `instanceof` check will continue to work for new inheriting classes. So that's future-proof.
|
||||
|
||||
Also it's important that if `catch` meets an unknown error, then it rethrows it in the line `(**)`. The `catch` only knows how to handle validation and syntax errors, other kinds (due to a typo in the code or such) should fall through.
|
||||
|
||||
## Further inheritance
|
||||
|
||||
The `ValidationError` class is very generic. Many things may go wrong. The property may be absent or it may be in a wrong format (like a string value for `age`). Let's make a more concrete class `PropertyRequiredError`, exactly for absent properties. It will carry additional information about the property that's missing.
|
||||
|
||||
```js run
|
||||
class ValidationError extends Error {
|
||||
constructor(message) {
|
||||
super(message);
|
||||
this.name = "ValidationError";
|
||||
}
|
||||
}
|
||||
|
||||
*!*
|
||||
class PropertyRequiredError extends ValidationError {
|
||||
constructor(property) {
|
||||
super("No property: " + property);
|
||||
this.name = "PropertyRequiredError";
|
||||
this.property = property;
|
||||
}
|
||||
}
|
||||
*/!*
|
||||
|
||||
// Usage
|
||||
function readUser(json) {
|
||||
let user = JSON.parse(json);
|
||||
|
||||
if (!user.age) {
|
||||
throw new PropertyRequiredError("age");
|
||||
}
|
||||
if (!user.name) {
|
||||
throw new PropertyRequiredError("name");
|
||||
}
|
||||
|
||||
return user;
|
||||
}
|
||||
|
||||
// Working example with try..catch
|
||||
|
||||
try {
|
||||
let user = readUser('{ "age": 25 }');
|
||||
} catch (err) {
|
||||
if (err instanceof ValidationError) {
|
||||
*!*
|
||||
alert("Invalid data: " + err.message); // Invalid data: No property: name
|
||||
alert(err.name); // PropertyRequiredError
|
||||
alert(err.property); // name
|
||||
*/!*
|
||||
} else if (err instanceof SyntaxError) {
|
||||
alert("JSON Syntax Error: " + err.message);
|
||||
} else {
|
||||
throw err; // unknown error, rethrow it
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The new class `PropertyRequiredError` is easy to use: we only need to pass the property name: `new PropertyRequiredError(property)`. The human-readable `message` is generated by the constructor.
|
||||
|
||||
Please note that `this.name` in `PropertyRequiredError` constructor is again assigned manually. That may become a bit tedious -- to assign `this.name = <class name>` when creating each custom error. But there's a way out. We can make our own "basic error" class that removes this burden from our shoulders by using `this.constructor.name` for `this.name` in the constructor. And then inherit from it.
|
||||
|
||||
Let's call it `MyError`.
|
||||
|
||||
Here's the code with `MyError` and other custom error classes, simplified:
|
||||
|
||||
```js run
|
||||
class MyError extends Error {
|
||||
constructor(message) {
|
||||
super(message);
|
||||
*!*
|
||||
this.name = this.constructor.name;
|
||||
*/!*
|
||||
}
|
||||
}
|
||||
|
||||
class ValidationError extends MyError { }
|
||||
|
||||
class PropertyRequiredError extends ValidationError {
|
||||
constructor(property) {
|
||||
super("No property: " + property);
|
||||
this.property = property;
|
||||
}
|
||||
}
|
||||
|
||||
// name is correct
|
||||
alert( new PropertyRequiredError("field").name ); // PropertyRequiredError
|
||||
```
|
||||
|
||||
Now custom errors are much shorter, especially `ValidationError`, as we got rid of the `"this.name = ..."` line in the constructor.
|
||||
|
||||
## Wrapping exceptions
|
||||
|
||||
The purpose of the function `readUser` in the code above is "to read the user data", right? There may occur different kinds of errors in the process. Right now we have `SyntaxError` and `ValidationError`, but in the future `readUser` function may grow: the new code will probably generate other kinds of errors.
|
||||
|
||||
The code which calls `readUser` should handle these errors. Right now it uses multiple `if` in the `catch` block to check for different error types and rethrow the unknown ones. But if `readUser` function generates several kinds of errors -- then we should ask ourselves: do we really want to check for all error types one-by-one in every code that calls `readUser`?
|
||||
|
||||
Often the answer is "No": the outer code wants to be "one level above all that". It wants to have some kind of "data reading error". Why exactly it happened -- is often irrelevant (the error message describes it). Or, even better if there is a way to get error details, but only if we need to.
|
||||
|
||||
So let's make a new class `ReadError` to represent such errors. If an error occurs inside `readUser`, we'll catch it there and generate `ReadError`. We'll also keep the reference to the original error in its `cause` property. Then the outer code will only have to check for `ReadError`.
|
||||
|
||||
Here's the code that defines `ReadError` and demonstrates its use in `readUser` and `try..catch`:
|
||||
|
||||
```js run
|
||||
class ReadError extends Error {
|
||||
constructor(message, cause) {
|
||||
super(message);
|
||||
this.cause = cause;
|
||||
this.name = 'ReadError';
|
||||
}
|
||||
}
|
||||
|
||||
class ValidationError extends Error { /*...*/ }
|
||||
class PropertyRequiredError extends ValidationError { /* ... */ }
|
||||
|
||||
function validateUser(user) {
|
||||
if (!user.age) {
|
||||
throw new PropertyRequiredError("age");
|
||||
}
|
||||
|
||||
if (!user.name) {
|
||||
throw new PropertyRequiredError("name");
|
||||
}
|
||||
}
|
||||
|
||||
function readUser(json) {
|
||||
let user;
|
||||
|
||||
try {
|
||||
user = JSON.parse(json);
|
||||
} catch (err) {
|
||||
*!*
|
||||
if (err instanceof SyntaxError) {
|
||||
throw new ReadError("Syntax Error", err);
|
||||
} else {
|
||||
throw err;
|
||||
}
|
||||
*/!*
|
||||
}
|
||||
|
||||
try {
|
||||
validateUser(user);
|
||||
} catch (err) {
|
||||
*!*
|
||||
if (err instanceof ValidationError) {
|
||||
throw new ReadError("Validation Error", err);
|
||||
} else {
|
||||
throw err;
|
||||
}
|
||||
*/!*
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
try {
|
||||
readUser('{bad json}');
|
||||
} catch (e) {
|
||||
if (e instanceof ReadError) {
|
||||
*!*
|
||||
alert(e);
|
||||
// Original error: SyntaxError: Unexpected token b in JSON at position 1
|
||||
alert("Original error: " + e.cause);
|
||||
*/!*
|
||||
} else {
|
||||
throw e;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In the code above, `readUser` works exactly as described -- catches syntax and validation errors and throws `ReadError` errors instead (unknown errors are rethrown as usual).
|
||||
|
||||
So the outer code checks `instanceof ReadError` and that's it. No need to list possible all error types.
|
||||
|
||||
The approach is called "wrapping exceptions", because we take "low level exceptions" and "wrap" them into `ReadError` that is more abstract and more convenient to use for the calling code. It is widely used in object-oriented programming.
|
||||
|
||||
## Summary
|
||||
|
||||
- We can inherit from `Error` and other built-in error classes normally, just need to take care of `name` property and don't forget to call `super`.
|
||||
- Most of the time, we should use `instanceof` to check for particular errors. It also works with inheritance. But sometimes we have an error object coming from the 3rd-party library and there's no easy way to get the class. Then `name` property can be used for such checks.
|
||||
- Wrapping exceptions is a widespread technique when a function handles low-level exceptions and makes a higher-level object to report about the errors. Low-level exceptions sometimes become properties of that object like `err.cause` in the examples above, but that's not strictly required.
|
||||
1
1-js/10-error-handling/index.md
Normal file
1
1-js/10-error-handling/index.md
Normal file
|
|
@ -0,0 +1 @@
|
|||
# Error handling
|
||||
Loading…
Add table
Add a link
Reference in a new issue