search

deepwell / meteor-raven

Raven/Sentry integration package for Meteor
29 stars 10 forks source link

Initialization Code #7

Closed rgould closed 10 years ago

rgould commented 10 years ago

We found that in order to get this working nicely on Heroku, we had to add some initialization code to pass the SENTRY_DSN variable to the client. We also don't want to pass the private key to the client.

We also noticed that exceptions in certain closures were being caught by Meteor and not re-thrown. We've added a dirty, temporary hack (where we hijack Meteor._debug) to catch these errors.

We've integrated this code into our fork, and would be happy to see it integrated back, if you're interested. You can see an overview of our major changes in this gist:

https://gist.github.com/rgould/9522350

What's left to do?

1) Add error handling to Meteor so that we can remove the hack 2) Catch uncaught errors on the client. Raven doesn't try to do anything with window.onerror, but I still think there's value in trying to do so (especially on Chrome, which includes the stacktrace)

(Not sure if this is the best place for a discussion like this. Feel free to email me at richard@okgrow.com)

rgould commented 10 years ago

Aha, I was mistaken about not catching uncaught errors on the client. I see that raven.js uses Tracekit to handle window.onerror callbacks.

deepwell commented 10 years ago

That's interesting "certain closures were being caught by Meteor and not re-thrown". I haven't noticed this, but maybe that's because the errors weren't thrown! Do you have a small example code that could exhibit this behaviour?

Secondly, do you use a settings.json file? We put the private DSN in the server scope, and then the public DSN in the public scope (as all public settings are sent to the browser). If you could do that, it would alleviate the need for you to do a meteor method call every time someone loads the app. I would also think it's possible some exceptions could be missed in this case while the meteor method call is running.

rgould commented 10 years ago

I tried writing up a small app to demonstrate this problem, but wasn't able to replicate it. I'm guessing I was probably just really confused.

And settings.json is a good solution for handling private/public scope. The project that we were heavily using this for has been mothballed for a bit, but we'll likely revisit this in the coming months.