Bug 816007 - RFE: Streamlined error format
RFE: Streamlined error format
Status: CLOSED WONTFIX
Product: PressGang CCMS
Classification: Community
Component: CSProcessor (Show other bugs)
1.x
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Lee Newson
:
: 815588 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-24 23:35 EDT by Joshua Wulf
Modified: 2014-10-19 19:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-28 22:22:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joshua Wulf 2012-04-24 23:35:16 EDT
I'm finding the ERROR report a little busy, so I've made a suggested format that I would find easier to parse.

Present:

ERROR: Line 70: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Last Value Queues [8229]
       -> Topic 8229: Override the Default Group Name
ERROR: Line 80: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Rejected and Orphaned Messages [8035]
       -> Topic 8035: Queue Deletion Checks
ERROR: Line 84: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Queue Threshold Alerts [8180]
       -> Topic 8180: Queue Flow Control Properties
ERROR: Line 98: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Specify Queue Flow Thresholds with qpid-config [6974]
       -> Topic 6974: Durable Queues
ERROR: Line 65: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Message Queue [8227]
       -> Topic 8227: Message Group Example Use Cases

Suggested:

ERROR: Content Spec contains invalid content

Line          
     Specified Title does not match Topic
70         Last Value Queues [8229]
           8229: Override the Default Group Name     
     Specified Title does not match Topic
80         Rejected and Orphaned Messages [8035]
           8035: Queue Deletion Checks
     Specified Title does not match Topic
84         Queue Threshold Alerts [8180]
           8180: Queue Flow Control Properties
Comment 1 Joshua Wulf 2012-04-25 00:52:58 EDT
Mashing up with the formatting suggestion in https://bugzilla.redhat.com/show_bug.cgi?id=815588 (missing tags)

Also, inserting a line to make it clear where an error report entry begins and ends. 

Cutting and pasting an error output like this into a text editor makes a handy task list for fixing the Content Spec after a large update.

ERROR: Invalid Content Specification

Line          
     Non-existent tag:
69      [QMF]

     Specified Title does not match Topic:
70      Last Value Queues [8229]
        8229: Override the Default Group Name 

     Non-existent tags: 
75      [Qpid API Class, PiAQ-2]   

     Specified Title does not match Topic:
80      Rejected and Orphaned Messages [8035]
        8035: Queue Deletion Checks

     Specified Title does not match Topic:
84      Queue Threshold Alerts [8180]
        8180: Queue Flow Control Properties
Comment 2 Lee Newson 2012-04-25 03:33:16 EDT
That just looks even worse to read in my opinion. Also the ERROR is a keyword and shouldn't be omitted, as some messages are DEBUG and some INFO. My initial suggestion would be to just separate each error with a blank line. After that some of the text could be removed and re-arranged. I'm still unsure about keeping the line output there, as it was something you yourself requested and quite persistently I might add. From memory your reasoning was that it makes it much easier to see where the error was coming from. I would be in favor of removing it for better error messages though. Maybe some thing like:


ERROR: Line 69: Unable to find Tag(s) on the server.
       Tags -> QMF

ERROR: Line 70: The title for topic 8229 doesn't match.
       Local  -> Last Value Queues
       Server -> Override the Default Group Name

ERROR: Line 80: The title for topic 8035 doesn't match.
       Local  -> Rejected and Orphaned Messages
       Server -> Queue Deletion Checks

ERROR: Line 84: The title for topic 8180 doesn't match.
       Local  -> Queue Threshold Alerts
       Server -> Queue Flow Control Properties

ERROR: Line 98: The title for topic 6974 doesn't match.
       Local  -> Specify Queue Flow Thresholds with qpid-config
       Server -> Durable Queues

ERROR: Line 65: The title for topic 8227 doesn't match.
       Local  -> Message Queue
       Server -> Message Group Example Use Cases

The idea behind this layout is initially error type, which is separated to easily see errors or info messages.Then after that is the place of the error and the type of error. The following lines are then used to further expand on the error message by giving the exact issue.
Comment 3 Lee Newson 2012-04-25 03:38:40 EDT
For the printing the line the error occurred on perhaps the debug information
could be fine tuned so level 1 would just display the lines (before or after
the error). Then actually make more debug output for different levels.
Comment 4 Lee Newson 2012-04-25 03:39:44 EDT
*** Bug 815588 has been marked as a duplicate of this bug. ***
Comment 5 Joshua Wulf 2012-04-25 06:34:17 EDT
Putting a new line between each entry looks good, but ERROR on every line still looks like overkill to me.

If there are INFO, WARN, and ERROR information in the same output, then how about doing it like this:

INFO


WARN


ERROR

What I've noticed after using it regularly for some time is this: once you learn what and where ERROR messages are, having the "ERROR" label there in every case becomes distracting. So making an ERROR section, where everything in it is an ERROR is less visually cluttered.

By "Line output" do you mean the line number? If so, in the format I gave above the Line number is in the left-most column, under the column header "Line". that's definitely necessary for debugging.

Again, once you know where the line number is, having "Line Number:" in front of every entry becomes cluttered.

Here's a comparison of the two:

ERROR: Line 65: The title for topic 8227 doesn't match.
       Local  -> Message Queue
       Server -> Message Group Example Use Cases

ERROR:

Line

     Specified Title does not match Topic:
65      Message Queue [8227]
        8227: Message Group Example Use Cases

In this one, everything in this section is an ERROR, so there is no need to put ERROR multiple times. 

The Error message appears first, on its own line. Each information element appears on its own line, so you can scan up and down. Putting multiple things on the same line (message type, line number, error message) means you need to scan up and down, and left and right to extract information.

The line number is always the number on the left, so there is no need to put the label "Line Number:" multiple times. 

Line 65 of the Content Spec is reproduced verbatim.

Following that line is the topic number and title from the server.

It easy to infer that the bottom one is the one from the server, and someone only needs to be told this once to get it. It doesn't need to be label in every instance, every time.

So perhaps what we're looking at is the difference between someone using it for the first time, who needs flashing lights to explain everything to them, versus someone who has been using it for a while, and wants the flashing lights to go away.....

I don't know how much effort it would be to have a beginner and expert mode for output, so for beginners it gives you the "labels on every instance of every thing" and for experienced users it gives you "just the facts - laid out logically".
Comment 6 Joshua Wulf 2012-04-25 06:37:17 EDT
"Then actually make more debug output for different levels."
https://bugzilla.redhat.com/show_bug.cgi?id=816004#c2

snap!
Comment 7 Lee Newson 2012-04-25 18:52:02 EDT
"By "Line output" do you mean the line number? If so, in the format I gave above
the Line number is in the left-most column, under the column header "Line".
that's definitely necessary for debugging."

No i was referring to printing the whole contents of the line in which the error occurred. I thought there might have been a bugzilla for it but it must have been before we started using bugzilla. See the previous posted current output for an example.

"Putting multiple things on the same line (message type, line number, error message) means you need to scan up and down, and left and right to extract information."

As for this the content is always in the same place it never moves an inch so I hardly see how the example I gave is any different is respect to having to look in different places. The example you gave does separate the content though, which I believe is the point you were trying to make.

Also with your current output what if you have say 100 errors? Then it becomes hard to see if something is an error or something else. You'd have to scroll all over the place to find what section of output your looking at. As for the line numbers they look out of place and just look like random jargon when placed in bulk. Your example is more setup for a table style output that has easily visible column/row markers which doesn't really work only using stdout.

I believe what you more looking at is a spreadsheet style output to define the work you need. So perhaps a csv type output that could be loaded into excel/calc would be more useful.
Comment 8 Misty Stanley-Jones 2013-05-28 22:22:16 EDT
This seems out of date. Reopen if I'm wrong.

Note You need to log in before you can comment on or make changes to this bug.