squash! ellipsis

doc/api/errors.md

@@ -31,7 +31,7 @@ called.
 
 All JavaScript errors are handled as exceptions that *immediately* generate
 and throw an error using the standard JavaScript `throw` mechanism. These
-are handled using the [`try/catch` construct][try-catch] provided by the
+are handled using the [`try…catch` construct][try-catch] provided by the
 JavaScript language.
 
 ```js
@@ -45,7 +45,7 @@ try {
 ```
 
 Any use of the JavaScript `throw` mechanism will raise an exception that
-*must* be handled using `try/catch` or the Node.js process will exit
+*must* be handled using `try…catch` or the Node.js process will exit
 immediately.
 
 With few exceptions, _Synchronous_ APIs (any blocking method that does not
@@ -90,7 +90,7 @@ Errors that occur within _Asynchronous APIs_ may be reported in multiple ways:
 
 - A handful of typically asynchronous methods in the Node.js API may still
  use the `throw` mechanism to raise exceptions that must be handled using
- `try/catch`. There is no comprehensive list of such methods; please
+ `try…catch`. There is no comprehensive list of such methods; please
  refer to the documentation of each method to determine the appropriate
  error handling mechanism required.
 
@@ -116,7 +116,7 @@ setImmediate(() => {
 });
 ```
 
-Errors generated in this way *cannot* be intercepted using `try/catch` as
+Errors generated in this way *cannot* be intercepted using `try…catch` as
 they are thrown *after* the calling code has already exited.
 
 Developers must refer to the documentation for each method to determine
@@ -149,7 +149,7 @@ fs.readFile('/some/file/that/does-not-exist', errorFirstCallback);
 fs.readFile('/some/file/that/does-exist', errorFirstCallback);
 ```
 
-The JavaScript `try/catch` mechanism **cannot** be used to intercept errors
+The JavaScript `try…catch` mechanism **cannot** be used to intercept errors
 generated by asynchronous APIs. A common mistake for beginners is to try to
 use `throw` inside an error-first callback: