If raygun is down or responding with error all messages are silently destroyed about raygun4net

[joshrobb]

You cannot just silently destroy an application's capability to record unhandled exceptions.

This isn't silently destroying anything. It's up to the developer to decide how to integrate raygun into their application.

We don't mark the error as handled - where you choose to insert Raygun into your application is up to you. If you can't afford the possibility of losing a single error report - then you can wire up other logging solutions (log4net, NLog, System.Diagnostics).

We could queue errors if the API is returning bad results - but then if the application closes (or the asp.net app domain spins down) we'd have to persist these somewhere - and re-send them later - which is all getting pretty complex. (Multi-threadded transactional storage for temporary persistance etc).

We'd love to hear any other suggestions you have.

[dotnetchris]

For you to have an API that is Handle(error) that returns with no issue when in fact it failed, yes you are silently destroying the exceptions.

Either you should

try { }
catch(Exception e)
{ throw new RaygunError(e, orginal exception / raygun message) }

Or expose an event to be hooked into for raygun errors just like i said in the original issue text.

[martin308]

As @joshrobb said we are not silently destroying the exceptions as we don't mark them as handled, so they will continue to bubble up to any other logging that you may have.

It would be "beyond bad practice" for a logging framework to throw an exception if it couldn't log, take a look at the NLog source which does something similar.

Again happy to look at any ideas you have in a PR 👍

[dotnetchris]

Sigh, seeing this closed nearly cost you a customer. You're lucky AppFail's client is heavily bonded to the web.config its impossible for us to use without it polluting our web.config with gunk, and fixing that would would require substantial amounts of effort I have no interest in and I doubt AppFail would either. I'll have a pull request for properly exposing the event tomorrow either done myself or one of my employees.

[dotnetchris]

Well atleast I realize from seeing on other issues the repeated usage of PR, assumingly meaning pull request, is much less of "go away".

[martin308]

Bingo, always keen to see new ideas for how to handle things. It's much easier to debate working code