|
42 | 42 |
|
43 | 43 | <p> |
44 | 44 |
|
45 | | - The following server implementation checks if a client-provided |
46 | | - file path is valid and throws an exception if the check fails. It can |
47 | | - be seen that the exception is uncaught, and it is therefore reasonable to |
48 | | - expect the server to respond with an error response to client requests |
49 | | - that cause the check to fail. |
50 | | - |
51 | | - But since the exception is uncaught in the context of an |
52 | | - asynchronous callback invocation (<code>fs.access(...)</code>), the |
53 | | - entire server will terminate instead. |
| 45 | + The following server code checks if a client-provided file path is valid |
| 46 | + before saving data to that path. It would be reasonable to expect that the |
| 47 | + server responds with an error in case the request contains an invalid |
| 48 | + file path. However, the server instead throws an exception, which is |
| 49 | + uncaught in the context of the asynchronous callback invocation |
| 50 | + (<code>fs.access(...)</code>). This causes the entire server to |
| 51 | + terminate abruptly. |
54 | 52 |
|
55 | 53 | </p> |
56 | 54 |
|
|
67 | 65 |
|
68 | 66 | <p> |
69 | 67 |
|
70 | | - An alternative is to use an <code>async</code> and |
71 | | - <code>await</code> for the asynchronous behavior, since the server |
72 | | - will then print warning messages about uncaught exceptions instead of |
73 | | - terminating, unless the server was started with the commandline option |
74 | | - <code>--unhandled-rejections=strict</code>: |
| 68 | + To simplify exception handling, it may be advisable to switch to |
| 69 | + async/await syntax instead of using callbacks, which allows wrapping the |
| 70 | + entire request handler in a <code>try/catch</code> block: |
75 | 71 |
|
76 | 72 | </p> |
77 | 73 |
|
|
0 commit comments