Implement a Blocking/Synchronous Error Reporting Method

[rollbar]

Implement a Blocking/Synchronous Error Reporting Method

[FrankyB5]

Hi thanks for creating this issue.
Just to let you know, I managed to skip the unhandled exception UI (thus not calling anymore the Environment.Exit function):

https://msdn.microsoft.com/en-us/library/windows/desktop/ms680621%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
SetErrorMode(ErrorModes.SEM_NOGPFAULTERRORBOX);

But even without the Environment.Exit, the same problem is there.
When handling the AppDomain.CurrentDomain.UnhandledException, not long after being notified will the process be shut down.

I need to know in a way, that when calling the RollbarInstance.Critical(exception) function, I want to be sure that "That log entry" is sent.
Currently, here's what I need to do to achieve this:
`
var eventSent = new ManualResetEvent(false);
RollbarQueueController.Instance.InternalEvent += (o, args) =>
{
if (args is CommunicationEventArgs communicationArgs && communicationArgs.Response.Error == 0)
{
eventSent.Set();
}
};

                RollbarLocator.RollbarInstance.Critical(exception);

                //For now wait a little hoping that Rollbar has enough time to send the event
                if (!eventSent.WaitOne(TimeSpan.FromSeconds(1)))
                {
                    GlobalFactory.Instance.Resolve<TraceSource>().TraceEvent(TraceEventType.Error, 0, "Could not send Rollback event! Timeout reached");
                }

`

Currently I need to know how the internals of the communication work in order to make sure it's being sent

• CommunicationEventArgs seems to be sent when successful
• It's error will be == 0 (since RollbarApiErrorEventArgs derives also from CommunicationEventArgs, that's another way to make sure that all was successful)
• And if I've read correctly, it tries 3 times with 250ms delays, so basically that should all be finished in about 750ms.

Life would be easier if calling the "Critical" method would return me a Task which I could await (or similar idea), or else a token/item on which I could subscribe to an event.

[akornich]

I see where are you going with this. And it does make sense and would work fine if the reported info was reported individually. However, we have a requirement to support multiple instances of RollbarLogger potentially configured for different Rollbar access tokens. They all have to obey reporting rate limits per access token. So, internally we allocate payloads from the reported info on background threads and placing payloads in proper processing queue which is part of a queue collection and then have one processing thread that cycles all the queues and processes the queued payloads while obeying predefined reporting rates and doing re-sends as needed.

[FrankyB5]

Or maybe is there another way to achieve this? Maybe this issue is not a problem, but a bad usage of the framework?
I'm seeing Rollbar as primary's goal being an exception reporter (thus especially the unhandled ones would be the main concern and the most "wanted to be reported").
So, when an unhandled exception is happening, how do your other users properly send the exception to Rollbar?

[akornich]

Nope, you are not misusing the notifier and you are properly waiting for the communication event. Reporting unhandled exceptions is only one of the purposes of Rollbar. Reporting "expected" exceptions is another one and simple remote logging as well. We try to make it as less intrusive as possible (as any instrumentation tool should be) so its activities affect main operation of the hosting application as little as possible. That is why all the reporting functionality happens in async mode by default.
We are thinking about adding a wrapper class that would internally synchronize/block the reporting process so it could be used easily in scenarios like yours. Internally, it would do things similar to what you prototyped above.

[akornich]

implemented in v1.0.2