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
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
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.
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.
*** Bug 815588 has been marked as a duplicate of this bug. ***
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".
"Then actually make more debug output for different levels." https://bugzilla.redhat.com/show_bug.cgi?id=816004#c2 snap!
"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.
This seems out of date. Reopen if I'm wrong.