search

PandaWood / ExceptionReporter.NET

ExceptionReporter is a .NET component that gathers detailed information on an Exception and the application/system running it. It allows the user to copy, save or send a custom-formatted report to the developer
MIT License
51 stars 32 forks source link

Feature request: include additional custom data in the generated report #6

Open CrushaKRool opened 7 years ago

CrushaKRool commented 7 years ago

Hi, it would be nice if there was a way to supply additional data to the exception reporter. This may be contextual state information that the application has available (and which is not included in the thrown exception) that could help in analyzing the issue.

Perhaps this could be passed in as additional string parameter of the Show() method. If supplied, it could then be shown in a separate tab of the UI and would also be included in the different outputs that can be generated.

PandaWood commented 7 years ago

Thanks, yes there's already an override of Show() with a string for CustomMessage, but this custom data proposal of yours will be different for each exception, so yes we'd have to expose in the Show(), I think.

If we also add it to the ExceptionReportInfo (config) class then we can cater for the dialog-free technique of using the ExceptionReportGenerator class, ie without the Show() method.

CrushaKRool commented 7 years ago

Yeah, the CustomMessage is not included in the generated reports, so it wouldn't be much use to the developers receiving the report.

Personally, I tend to set CustomMessage to a combined list of the message of the exception and its inner exceptions. (Basically a condensed stacktrace without the actual code references) While the users may not have as much use for it as developers, they still might get an idea about what exactly is going awry and whether its something they should report or could fix on their own when that window pops up.

I was pondering whether it might be a good idea to just pass a Function delegate to the ExceptionReporter and let it retrieve the custom data that way. However, such a delegate would then probably be limited to what data is globally accessible, rather than getting it from the current thread of execution. Both would work in my scenario, but I guess a simple parameter is more suitable for the majority of use cases.

PandaWood commented 7 years ago

Yes, we could make the custom data a string (that might confused the Show() method overrides... or an Object (that we call ToString() on it) or we could make our own class for it, just to make the API explicit (class CustomData) that you have to instantiate or we could just make it an interface ICustomData, with a ToString() assumption but then add whatever you need...

PandaWood commented 7 years ago

... or a Function delegate as you mentioned...

PandaWood commented 6 years ago

Actually, I'm also in the middle of a large refactor in the design of the classes that "Send" MailSender/SmtpSender/WebServiceSender/MapiSender https://github.com/PandaWood/ExceptionReporter.NET/compare/isender

So I might have to hold off on some of these changes. But all your thinking is correct on the separation and design.

PandaWood commented 6 years ago

BTW I was able to compile this project on Mono/Mac until a few days ago when we added support for ClickOnce deployed applications. Checking the version on a deployed application requires an assembly reference that Mono has absolutely no support for, so sadly, cross-platform support is now impossible. Especially since the latest mono compiler removed conditional compilation. There's just no way to compile it now

PandaWood commented 6 years ago

And Xamarin is owned by Microsoft and is now "Visual Studio for Mac" - which is what I'm using. So nothing changes I'm afraid ;-)

SlyFoxHayes commented 6 years ago

We can take support for ClickOnce out, and just provide a code example of how to populate the AppVersion with the ClickOnce version (I started out this way). Or create a ClickOnce only assembly and NuGet release (i.e. ExceptionReporter.NET.ClickOnce), that uses ExceptionReport.NET as a dependency. Admittedly, a whole new NuGet project for what ultimately amounts 2 two lines of code to get the ClickOnce Version seems like overkill.

PandaWood commented 6 years ago

I'm OK with the ClickOnce support. There's a lot of other code that wouldn't run under Mono either - the system information gathering, the screenshot taking.

I put code in to check for Mono and not run those bits of code. A few months ago, I could run the ExceptionReporter under Mono, but the UI was "frozen" - Mono only has limited support for WinForms.

As of a few months ago, Mono just crashes without showing the dialog. Nothing we changed.