Difference between revisions of "Improve error handling/reporting"

From VistrailsWiki
Jump to navigation Jump to search
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
* Splash screen now shows package initialization
= Dave's comments =


* Classifying log levels
* The buttons in the messages window should all be aligned to the right-side of the window so that resizing doesn't add space between them.
** debug 10 (cannot be accessed by setting loglevel)
** log(info) 20
** warning 30
** critical 50


*~800 print statements in VisTrails + 200 commented ones
* We need to go through the code to make sure our messages adhere to a format that makes this work.
** For some of the invalid pipeline messages, they start with a '-' which makes them look weird in the new gui.
** We need to redo a bunch of the existing gui messages (like those that use QMessageBox.critical directly...).


* Translating issues
* Colorcodes work
** core/upgradeworkflow.py
** I'm not sure we need more than red and black, but I like red for critical.
*** debug.critical('Package cannot handle upgrade request. VisTrails will attempt automatic upgrade.') - Should it be critical?
 
> * The MessageBox that displays error messages is similar to the one used for "Invalid pipeline" messages in
> gui.vistrail_controller. Do you think it works?
* How to display multiple error messages
** On startup, I only see the last error as a MessageBox.  It would seem that when we get multiple errors, we should display them in a format more like the messages windows.
** On the Mac, you can't resize this box.  Is it possible to make this larger and resizeable?
 
* "copy message" works.
** We could also use Qt's QDesktopServices.openUrl to have a "Send to VisTrails..." button that generates a message with all of the necessary information and a given address (maybe something like vistrails-debug@sci.utah.edu?) and allows the user to send it via their email client.
 
* To get more informative messages I allow the logging functions to accept multi-line messages where the first line is the short message and the rest are used as detailed information. Do you think this is a good idea?
 
* Logging accepts multiline messages where the first one is the summary and the rest is a more detailed message.
** Another way is to get developers to think about this correctly by adding specific arguments to the function call so that there are two arguments (message, expanded_msg).  For backward compatibility, we can default expanded_msg to None and use the multi-line heuristic to break up the message in that case.

Latest revision as of 19:33, 23 November 2010

Dave's comments

  • The buttons in the messages window should all be aligned to the right-side of the window so that resizing doesn't add space between them.
  • We need to go through the code to make sure our messages adhere to a format that makes this work.
    • For some of the invalid pipeline messages, they start with a '-' which makes them look weird in the new gui.
    • We need to redo a bunch of the existing gui messages (like those that use QMessageBox.critical directly...).
  • Colorcodes work
    • I'm not sure we need more than red and black, but I like red for critical.

> * The MessageBox that displays error messages is similar to the one used for "Invalid pipeline" messages in > gui.vistrail_controller. Do you think it works?

  • How to display multiple error messages
    • On startup, I only see the last error as a MessageBox. It would seem that when we get multiple errors, we should display them in a format more like the messages windows.
    • On the Mac, you can't resize this box. Is it possible to make this larger and resizeable?
  • "copy message" works.
    • We could also use Qt's QDesktopServices.openUrl to have a "Send to VisTrails..." button that generates a message with all of the necessary information and a given address (maybe something like vistrails-debug@sci.utah.edu?) and allows the user to send it via their email client.
  • To get more informative messages I allow the logging functions to accept multi-line messages where the first line is the short message and the rest are used as detailed information. Do you think this is a good idea?
  • Logging accepts multiline messages where the first one is the summary and the rest is a more detailed message.
    • Another way is to get developers to think about this correctly by adding specific arguments to the function call so that there are two arguments (message, expanded_msg). For backward compatibility, we can default expanded_msg to None and use the multi-line heuristic to break up the message in that case.