Feature request: JSON format

delphi package - automated exception handling

Feature request: JSON format

Postby StephaneGrobety » Fri Nov 29, 2019 8:30 am

Hello,

I'm struggling a bit to integrate the crash report with our Azure Devops managment system. My main limitation now is that I cannot process the clear text crash report. In order to solve this (and facilitate integration with bug tracking software), I would like to sugges that the crash report attachement be (optionally) generated in JSON format. That would allow me to write sorting rules that could clear up a LOT of things:
- Auto-detect duplicate reports from different customers.
- Locat the code revision that caused the crash.
- Route the report to the correct module/team/team member.
- Auto-drop (some) allready corrected bugs.

XML would work as well but it's much less convenient to work with with the tools at my disposal (MS Flow and Azure Devops)
StephaneGrobety
 
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

Re: Feature request: JSON format

Postby madshi » Fri Nov 29, 2019 8:42 am

Well, you can use RegisterExceptActionHandler() to be notified when madExcept sends out a bug report, and in that case you can walk through the properties of the "exceptIntf: IMEException" interface to create any kind of bug report format you like.

Of course I could also do this within madExcept, but honestly, you're the first user who asks for this, and offering this as an option would increase the code footprint for every madExcept user.
madshi
Site Admin
 
Posts: 10098
Joined: Sun Mar 21, 2004 5:25 pm

Re: Feature request: JSON format

Postby StephaneGrobety » Wed Dec 04, 2019 8:53 am

Of course I could also do this within madExcept, but honestly, you're the first user who asks for this, and offering this as an option would increase the code footprint for every madExcept user.


Thank you for your answer. I have seveeral things to say to this:

1/ You switched to a subscription model to support the product (which is fine, really: I'm all for it). But this suggest that you intend to expand the feature set of the software as well as provide support to the existing code. In such a case, accepting feature requests from subscribers seems logical even if you don't get 20 requests for the same feature. Now considering there is no public "reature request" system in place, the argument "you're the first user who asks for this" seems pretty weak to me avdn eve counter-productive: assuming you implement it just for me and that I (or anyone else) uses that feature to provide clear direction to integrate ME bug reporting with Azure Devops (or github's issue tracking or Atlasian JIRA or any other), then it'll be an advantage for every other potential user.
2/ I can't fully perform the job on my own because the source code to recompile the devs tools (in particular, the viewer) isn't provided.
3/ I can see several ways of implementing this without increasing the runtime footprint for everyone that doesn't need it, really.
StephaneGrobety
 
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am


Return to madExcept

Who is online

Users browsing this forum: No registered users and 12 guests

cron