Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unhandled exception should still be printed to the Console #6

Open
steren opened this issue Nov 29, 2016 · 9 comments
Open

Unhandled exception should still be printed to the Console #6

steren opened this issue Nov 29, 2016 · 9 comments

Comments

@steren
Copy link
Collaborator

steren commented Nov 29, 2016

Setting up this module hides errors from the Chrome console. This is not good for debugging

@steren steren added the bug label Nov 29, 2016
@oshalygin
Copy link
Contributor

I'm on the fence about this one, while its nice to see the errors, in local development the package should be not initialized. In your live environment, there's little benefit in the users of the application to see the errors, and as a developer you can see all of the errors in the stackdriver dashboard.

Thoughts @steren ?

@steren
Copy link
Collaborator Author

steren commented May 16, 2017

That's a good point that in local dev, it's better to not initialize the module.

I still wonder if in a scenario of troubleshooting a customer issue, it's convenient to ask the customer: "open the Chrome console, is there any errors there?".

@steren steren added enhancement and removed bug labels May 16, 2017
@oshalygin
Copy link
Contributor

Very good point!

@Jastrzebowski
Copy link
Contributor

I would definitely agree with @steren in this case, but it should be an option which could be turned off in config if someone would still want to run logging silently.

@michalzubkowicz
Copy link

You should not break default browser behaviour. Sometimes one need to check by himself that is an error somewhere without access to stackdriver. How could he know that this script is running and errors are suppresed? It can lead to many problems.

For those who needs fix for this, just change return value of this function in source code from true to false:
window.onerror = function(message, source, lineno, colno, error) {
if(error){
that.report(error);
}
oldErrorHandler(message, source, lineno, colno, error);
return true;
};

Line 74 in current version

and then rebuild (npm run dist).

@aaomidi
Copy link

aaomidi commented Oct 21, 2018

What about just make this configurable?

@amirnissim
Copy link

amirnissim commented Sep 1, 2019

another possible workaround:

import StackdriverErrorReporter from "stackdriver-errors-js";

const errorReporter = new StackdriverErrorReporter();

function startReportingUnhanldedErrors() {
  // 1. report errors to stackdriver
  errorReporter.start(YOUR_CONFIG);
  const stackdriverErrorHandler = window.onerror;
  window.onerror = () => {
    stackdriverErrorHandler(...arguments);
    // 2. log errors to the console (default browser behavior)
    return false;
  };
}

@KutnerUri
Copy link

the bad thing is that StackDriver automatically makes the decision for you, violating Inversion of Control.
It could be especially bad when there are other handlers that monitor the console (Winston, for example)

should be disabled by default, or configurable.

@palamccc
Copy link

@oshalygin, @steren

  • A lot of small companies, don't have strict QA, and they ship products with bugs and fix bugs on production (hello, can you send the screenshot of the console ?). In this case, Whenever something is not working, we can't go to stackdriver and refresh the screen every few seconds to see any new error is captured.
  • Other error-capturing (ex: sentry) libraries do print unhandled errors on the console. That's what console is for.
  • In local development, I was running this library, with disabled = true, in this mode also errors are swallowed (errors not printed, errors not sent to the server).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants