docs: Document collectWindowErrors option

[kamilogorek]

Resolves #1049

[kamilogorek]

I just realised that uncaught/caught wording... would appreciate native speaker input.

[crccheck]

"uncaught" sounds good to me, but if I were to tweak things, I would say:

By default, Raven collects all uncaught errors that have been caught by the onerror handler. You can disable this behaviour by setting this flag to false. This may be useful when you only want to manually handle errors by using the captureMessage and captureException.

[kamilogorek]

Thanks @crccheck!

[benvinegar]

So, in the interest of aligning APIs, have we considered what form this would take in raven-node? e.g. should this be renamed collectGlobalErrors? Note that we already have captureUnhandledRejections in raven-node as the closest comparable thing, so maybe this should be captureUnhandledGlobalErrors? Should it also prevent try/catch instrumentation? Not clear that this config option does (e.g. Raven may still wrap async functions and still collect global errors).

Don't need to rush this out, the behavior is already present by just not calling .install. Let's make sure we have the naming right first.

[benvinegar]

by using the captureMessage and captureException.

Drop unnecessary the. Should just be "by using captureMessage and captureException".

[mitsuhiko]

Just needs the sentence fix, otherwise good to go.

taking this one

[benvinegar]

@mitsuhiko re-read my comments, I think this has to be re-thought

[kamilogorek]

There's similar issue in raven-node now – getsentry/raven-node#307

We have 3 separate calls during installation process:

process.on('uncaughtException', ...) // global error handler
process.on('unhandledRejection', ...) // global promises handler
instrumentor.instrument(..., ...) // global breadcrumbs handler

Only unhandledRejection is configurable by using captureUnhandledRejections.

However, for raven-js, we call:

TraceKit.report.subscribe // global error handler
self._instrumentTryCatch()  // global try/catch handler
self._instrumentBreadcrumbs() // global breadcrumbs handler

And only latter 2 are configurable through autoBreadcrumbs and instrument options.

So we have:

• global error handlers on both SDKs
• global breadrcumbs on both SDKs
• global try/catch on JS (@benvinegar why don't we instrument setTimeout/setInterval on node? Is there no need to do that there?)
• global promises handler on Node (unhandledrejection is not supported on IE/Edge/Firefox https://caniuse.com/#feat=unhandledrejection and if we'd want to use polyfill like https://github.com/rtsao/browser-unhandled-rejection we'd not be able to support IE11 anyway, as it doesn't support native Promises)

I'd love to unify both of those setups, eg.:
captureUncaughtExceptions/captureUncaughtErrors
captureUnhandledRejections
captureBreadcrumbs/autoBreadcrumbs
instrument + instrument as a dict (as it's done now for raven-js)

Thoughts? @getsentry/javascript

[kamilogorek]

More ref: #782

[sunknudsen]

Hey guys, trying to figure out how to disable Raven.js's onerror error handling to implement my own. The goal is to add extra data that isn't necessarily available at page load.

The following code snippet doesn't appear to work as two issues are reported (Raven.js's onerror and my own).

Raven.config('__DSN__', {
  allowDuplicates: true,
  collectWindowErrors: false
}).install();

Has collectWindowErrors been deprecated?

Also, is it possible to get Raven.js to report all xhr requests that return status codes in the 4** and 5**?

Thanks!

[danielhusar]

Looks like collectWindowErrors doesn't work any more.
You need to edit defaultIntegrations now.
This is how i have disabled the global handlers:

import { init, Integrations } from '@sentry/browser';
import { Integrations as CoreIntegrations } from '@sentry/core';

init({
  defaultIntegrations: [
    new CoreIntegrations.Dedupe(),
    new CoreIntegrations.InboundFilters(),
    new CoreIntegrations.FunctionToString(),
    new Integrations.TryCatch(),
    new Integrations.Breadcrumbs(),
    new Integrations.LinkedErrors(),
    new Integrations.UserAgent(),
  ],
});

Maybe there is a way how to just remove one default integration but I havent found it.

[kamilogorek]

@danielhusar it's right there in the docs https://docs.sentry.io/platforms/javascript/#removing-an-integration :)

Sentry.init({
  integrations(integrations) {
    return integrations.filter(i => i.name !== 'GlobalHandlers');
  }
});