search

oarevalo / BugLogHQ

BugLogHQ is a tool to centralize the handling of automated bug reports from multiple applications. BugLogHQ provides a unified view of error messages sent from any number of applications, allowing the developer to search, graph, forward, and explore the bug reports submitted by the applications.
http://www.bugloghq.com
154 stars 67 forks source link

Add "Template" and "LineNumber" to Entry schema. #50

Open cfchris opened 11 years ago

cfchris commented 11 years ago

In our old bug log that we wrote internally, we had the template and line number in the entry. So, doing aggregates and searching by template were easy. Would you be opposed to adding these as optional properties when submitting an entry?

oarevalo commented 11 years ago

Actually my plan is a bit different; what I want to do is make the stack trace a structured object that would get passed by the client into the listener. I don't want the application having to tell this to the client explicitly. This is something that the client can/should figure out on its own. Also, on the other hand I don't want the listener to have a gazillion arguments, so it needs to have a way for receiving structured data and then parsing it to get different things from it. Maybe getting something like a Json structure with well-known keys. But that's not something I want to tackle until I begin work on the 2.0 branch since it will be a significant change.

On Tue, May 28, 2013 at 3:19 PM, Chris Phillips notifications@github.comwrote:

In our old bug log that we wrote internally, we had the template and line number in the entry. So, doing aggregates and searching by template were easy. Would you be opposed to adding these as optional properties when submitting an entry?

— Reply to this email directly or view it on GitHubhttps://github.com/oarevalo/BugLogHQ/issues/50 .

Oscar Arevalo http://about.me/oarevalo http://www.coldbricks.com - Content Management System http://www.oscararevalo.com - My Blog

atuttle commented 11 years ago

I think you should at least support passing in file & line number optionally. I track a lot of JS errors in BLHQ, and the global JS error handler is handed the file name & line number. Getting a stack trace in JS is not (always) as easy.

cfchris commented 11 years ago

They could definitely be optional arguments. And if they are null, BugLogHQ could try and populate them from the exception info.

I think that including file and line in the way errors are grouped would significantly improve diagnostics. I have "Error Executing Database Query" 169 times already. But, they're form different lines in different files.