How to disable global exception handling

[leidegre]

How to disable global exception handling

[niemyjski]

Hey,

What script are you bringing into your project? All exceptions will be be deduped so you shouldn't worry about seeing duplicates, if you are that's a bug. There currently is no way to not register a global error handler because it's part of the bootstrapping process (https://github.com/exceptionless/Exceptionless.JavaScript/blob/master/src/exceptionless.ts#L77), Perhaps we could add a check here to not initialize it. The problem is, there is no way to get rid of that dependency and shrink by ~30KB without removing all exception reporting from the client (used to parse stack traces). The whole lib (exceptionless.min.js is 46.7 KB before gzip compression).

So to confirm you're just seeing a hit to load the library and you are trying to defer it? If you load it from the cdn, it will be cached by the browser crazy and you can even tell it to be loaded async.

[leidegre]

Yeah, it's mostly fine. The concern is around the UX for the first visitor. And we can make it better by simply deferring the error handling code to when the first error occur. We have various error handling code anyway that route errors to exceptionless that would be difficult for exceptionless to get to any other way.

We're using the exceptionless NPM package.

I'm fine with TraceKit, that's a non issue.

The idea is to simply defer the loading of the exceptionless package until we encounter an error, because we can do that and it will save us 1 additional request of 50K depending on how you look at it. Totally worthwhile for us, in this case.

I don't like this line of code

https://github.com/csnover/TraceKit/blob/master/tracekit.js#L130

TraceKit shouldn't install a global error handler, or at least I want to have some control of that. The stack trace normalization and all that is great!

I think the way the bootstrapping process works is great when you don't care about the error reporting subtleties. It's going to create some headache for us.

I'm considering adding support for a relaying API that forwards events from client to exceptionless but that has proven to be somewhat problematic because exceptionless picks up the server environment, or somehow adds more context from the server, I'm probably doing the relaying wrong.

There's also the offline support thing to consider, which is non trivial. We have issues with user connectivity to that the exceptionless client have been dealing with just fine.

[leidegre]

@niemyjski given our specific use case I think the best thing for us to do is to just proxy the raw exceptionless message format using our own backend.

Our backend is written in .NET what's the simplest way to send an exceptionless JSON document to your backend for processing?

[leidegre]

@niemyjski I think I know what to do, sorry to bother you.

[niemyjski]

Perhaps we should add an option to trace kit to allow a subscribe without a global handler and just use that, then add a flag onto exceptionless client that doesn't enable it. I think it would be best to probably just defer the client load client side until all of your app has been loaded.

[leidegre]

It does save a lot of work.