Sentry allows to create multiple Hubs with different DSNs on the same page.
This is great, since I can separately monitor each module/component in a micro-frontends setup.
My question is (and I can't find the answer in the docs): how does Sentry choose what DSN to use when it reports an unhandled exception?
What I found in the docs so far:
The Sentry SDK will automatically capture and report any unhandled error that happens in your application runtime without any additional configuration or explicit handling. Generally, unhandled errors are errors that aren't caught by any except (or try/catch) clause.
link
And the only mention of multiple Hubs is here.
Related
My WCF service is throwing Unauthenticated & Unauthorised Fault Exception based on some validation. I want to handle these fault exceptions globally and then show them using a custom JS popup.
Is there any way to do this at global level.
i am running a nodejs code (server.js) as a jxcore using
jx mt-keep:4 server.js
we have a lot of request hit per seconds and mostly transaction take place.
I am looking for a way to catch error incase any thread dies and the request information is
returned back to me so that i can catch that request and take appropriate action based on it.
So in this i might not lose teh request coming in and would handle it.
This is a nodejs project and due to project urgency has been moved to jxcore.
Please let me know if there is a way to handle it even from code level.
Actually it's similar to a single Node.JS instance. You have same tools and options for handling the errors.
Besides, JXcore thread warns the task queue when it catches an unexpected exception on the JS land (Task queue stops sending the requests back to this instance) then safely restarts the particular thread. You may listen to 'uncaught exception', 'restart' events for the thread and manage a softer restart.
process.on('restart', res_cb, exit_code){
// thread needs a restart (due to unhandled exception, IO, hardware etc..)
// prepare your app for this thread's restart
// call res_cb(exit_code) for restart.
});
Note: JXcore expects the application is up and running at least for 5 seconds before restarting any thread. Perhaps this limitation protects the application from looping thread restarts.
You may start your application using 'jx monitor' it supports multi thread and reloads the crashed processes.
I'm quite new to Express.js and one of the things that surprised me more at first, compare to other servers such as Apache or IIS, is that Express.js server crashes every time it encounters an uncatched exception or some error turning down the site and making it accessible for users. A terrible thing!
For example, my application is crashing with a Javascript error because a variable is not defined due to a name change in the database table.
TypeError: Cannot call method 'replace' of undefined
This is not such a good example, because I should solve it before moving the site to production, but sometimes similar errors can take part which shouldn't be causing a server crash.
I would expect to see an error page or just an error in that specific page, but turning down the whole server for these kind of things sounds terrifying.
Express error handlers doesn't seem to be enough for this purposes.
I've been reading about how to solve this kind of things in Node.js by using domains, but I found nothing specifically for Express.js.
Another option I found, which doesn't seem to be recommended in all cases, is using tools to keep running a process forever, so after a crash, it would restart itself. Tools like Forever, Upstart or Monit.
How do you guys deal with this kind of problems in Express.js?
The main difference between Apache and nodejs in general is that Apache forks a process per request while nodejs is single threaded, hence if an error occurs in Apache then the process handling that request will crash while the others will continue to work, in nodejs instead the only thread goes down.
In my projects I use monit to check memory/cpu (if nodejs takes to much resources of my vps then monit will restart nodejs) and daemontools to be sure nodejs is always up and running.
I would recommend using Domains along with clusters. There is example in doc itself at http://nodejs.org/api/domain.html. There are also some modules for expressjs https://www.npmjs.org/package/express-domain-middleware.
So when such errors occur use of domain along with cluster will help us separate context of where error occur and will effect only single worker in cluster, we should be logging them and disconnect that worker in cluster and refork it. We can then read logs to fix such errors that need to be fixed in code.
I was facing the same issue and I fixed using try/cache like this. So I created different route files and included each route files in try/cache block like this.
try{
app.use('/api', require('./routes/user'))
}
catch(e)
{
console.log(e);
}
try{
app.use('/api', require('./routes/customer'))
}
catch(e)
{
console.log(e);
}
What is the difference between the Google Places API and the Google Places Javascript Library?
The documentation for the Library doesn't talk about API keys, and as I was developing locally everything seemed to work just fine without one. But shortly after deploying the web app, it started throwing the following errors:
GET http://maps.googleapis.com/maps/api/js/AuthenticationService.Authenticate?1shttp%3A%2F%2Fopensaq.dev%2F&5e1&callback=_xdc_._obke7w&token=16494 403 (Forbidden)
GET https://maps.googleapis.com/maps/api/js/PlaceService.FindPlaces?1m6&1m2&1d4…SAQ&6sliquor_store&8e1&18m2&1b1&10u43536&callback=_xdc_._266p5k&token=1150 403 (Forbidden)
GET http://maps.googleapis.com/maps/api/js/QuotaService.RecordEvent?1shttp%3A%2F%2Fopensaq.dev%2F&4e1&5e0&6u1&7s2v1zkm&callback=_xdc_._dacmzn&token=54694 403 (Forbidden)
Did exceed a quota or something? What is each option intended for?
The library is a javascript API to make working with the API from JavaScript easier, as it has a set of objects that replace the direct API calls. It will call the API, so you have to conform to the requirements of the API limits. The library may also download related JS libraries that are needed to perform the operation too.
These rejections in theory could be the JS library relationships failing to download, but appear to be API rejections. This could be due to a limit, or a firewall restriction (if you have one or a proxy in place). Depending on the requirements of the API, some require a signature to be generated, and if that is missing, it will be forbidden too. Look in the documentation for what it returns 403; the API documentation usually spells it out.
It looks like I overlooked this: https://developers.google.com/maps/documentation/javascript/tutorial#api_key
It appears that I'm missing an API key.
Exceptions cause Node.js servers to crash. The common wisdom is that one needs to monitor Node.js processes and restart them on crash. Why can't one just wrap the entire script in a try {} catch {} or listen for exception events?
It's understood that catching all exceptions is bad because it leaves the interpreter in an unpredictable state. Is this actually true? Why? Is this an issue specific to V8?
Catching all exception does not leave the interpreter in a bad state, but may leave your application in a bad state. An uncaught exception means that something that you were expecting to work, failed, and your application does not know how to handle that failure.
For example, if your app is a web server that listens to port 80 for connections, and when the app launches the port is in use, an exception is raised. Your code may ignore it, and then the process may continue running without actually listening to the port, so the process will be futile, or handle it: print an error message, a warning, kill the other process, or any way you want it to be handled. But you can see why ignoring it is not a good idea.
Another example is failing to communicate with a database (dropping a connection, unable to connect, receiving an unexpected error). If you app flow does not catch the exception properly, but just ignores it, you may be sending the user an acknowledgement of an event that failed.
Exceptions are part of the event engine. Instead of wrapping in a try what you want to do is listen for that exception
http://debuggable.com/posts/node-js-dealing-with-uncaught-exceptions:4c933d54-1428-443c-928d-4e1ecbdd56cb Then respond in the proper manner.
As for the second part of your question:
It really depends on your application. You need to test to see if the exception is something more or less you expect. Sometimes an exception is real not just a file not found.