You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The stack trace associated with an error can be viewed in the error reporting console.
94
-
* If the `errors.report` method is given an `ErrorMessage` object built using the `errors.event` method, the stack trace at the point where the error event was constructed will be used.
95
-
* If the `errors.report` method is given an `Error` object, the stack trace where the error was instantiated will be used.
96
-
* If the `errors.report` method is given a string, the stack trace at the point where `errors.report` is invoked will be used.
// Using ES6 style imports via TypeScript or Babel
193
-
// import {ErrorReporting} from '@google-cloud/error-reporting';
194
-
195
-
// Instantiates a client
196
-
const errors = new ErrorReporting();
197
-
198
-
function respond(req, res, next) {
199
-
next(new Error('this is a restify error'));
200
-
}
201
-
202
-
const server = restify.createServer();
203
-
204
-
server.use(errors.restify(server));
205
-
server.get('/hello/:name', respond);
206
-
server.head('/hello/:name', respond);
207
-
208
-
server.listen(3000);
209
-
```
210
-
211
-
## Unhandled Rejections
212
-
213
-
Unhandled Rejections are not reported by default. The reporting of unhandled rejections can be enabled using the `reportUnhandledRejections` configuration option. See the [Configuration](#configuration) section for more details.
214
-
215
-
If unhandled rejections are set to be reported, then, when an unhandled rejection occurs, a message is printed to standard out indicated that an unhandled rejection had occurred and is being reported, and the value causing the rejection is reported to the error-reporting console.
216
-
217
-
## Catching and Reporting Application-wide Uncaught Errors
218
-
219
-
Uncaught exceptions are not reported by default. *It is recommended to process `uncaughtException`s for production-deployed applications.*
220
-
221
-
Note that uncaught exceptions are not reported by default because to do so would require adding a listener to the `uncaughtException` event. Adding such a listener without knowledge of other `uncaughtException` listeners can cause interference between the event handlers or prevent the process from terminating cleanly. As such, it is necessary for `uncaughtException`s to be reported manually.
// Using ES6 style imports via TypeScript or Babel
227
-
// import {ErrorReporting} from '@google-cloud/error-reporting';
228
-
229
-
// Instantiates a client
230
-
const errors = new ErrorReporting();
231
-
232
-
process.on('uncaughtException', (e) => {
233
-
// Write the error to stderr.
234
-
console.error(e);
235
-
// Report that same error the Cloud Error Service
236
-
errors.report(e);
237
-
});
238
-
```
239
-
240
-
More information about uncaught exception handling in Node.js and what it means for your application can be found [here](https://nodejs.org/api/process.html#process_event_uncaughtexception).
241
-
242
-
### Using an API Key
243
-
244
-
You may use an API key in lieu of locally-stored credentials. Please see [this document](https://support.google.com/cloud/answer/6158862) on how to set up an API key if you do not already have one.
245
-
246
-
Once you have obtained an API key, you may provide it as part of the Error Reporting instance configuration:
// Using ES6 style imports via TypeScript or Babel
252
-
// import {ErrorReporting} from '@google-cloud/error-reporting';
253
-
254
-
// Instantiates a client
255
-
const errors = new ErrorReporting({
256
-
projectId: '{your project ID}',
257
-
key: '{your api key}'
258
-
});
259
-
```
260
-
261
-
If a key is provided, the module will not attempt to authenticate using the methods associated with locally-stored credentials. We recommend using a file, environment variable, or another mechanism to store the API key rather than hard-coding it into your application's source.
262
-
263
-
**Note:** The Error Reporting instance will check if the provided API key is invalid shortly after it is instantiated. If the key is invalid, an error-level message will be logged to stdout.
264
-
265
-
### Long Stack Traces
266
-
267
-
The [longjohn](https://www.npmjs.com/package/longjohn) module can be used with this library to enable [long-stack-traces](https://github.com/tlrobinson/long-stack-traces) and updates an `Error` object's stack trace, by adding special line, to indicate an async jump. In `longjohn` version `0.2.12`, for example, a single line of dashes is included in a stack trace, by default, to indicate an async jump.
268
-
269
-
Before reporting an `Error` object using the `report` method of the `@google-cloud/error-reporting` module, the stack trace needs to modified to remove this special line added by `longjohn`. Since the `longjohn` module can be configured to have a custom line indicating an async jump, the process of removing the custom line should be handled by the user of the `longjohn` module.
270
-
271
-
The following code illustrates how to update an `Error`'s stack trace, to remove the default line of dashes added by `longjohn` to indicate an async jump, before reporting the error.
0 commit comments