Difference between revisions of "Improve error handling/reporting"

From VistrailsWiki
Jump to navigation Jump to search
 
(2 intermediate revisions by the same user 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...).


= Conversion issues =
* Colorcodes work
== core/upgradeworkflow.py ==
** I'm not sure we need more than red and black, but I like red for critical.
* print "module %s already handled. skipping" % module_id - log or warning?
** [DK] log is probably ok here
* debug.critical('Package cannot handle upgrade request. VisTrails will attempt automatic upgrade.') - Should it be critical?
** [DK] warning (or maybe even log) would be more appropriate


== core/analogy/__init__.py ==
> * The MessageBox that displays error messages is similar to the one used for "Invalid pipeline" messages in
*if _debug: print 'version_a:', version_a (and a lot of similar) - Is it currently being debugged? remove?
> gui.vistrail_controller. Do you think it works?
** [DK] for now, let's keep them as low-level debug but we should be able to clean this up
* 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?


== core/analogy/eigen.py ==
* "copy message" works.
* print m_i: remove?
** 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.
** [DK] yeah, most of the matrix prints can be commented out or removed


== core/bundles/installbundle.py ==
* 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?
* A lot of print statements are used for installing deb/rpm packages. I am not sure if I can remove any.
** [ES] I think all the print statements outside the show_question() function can be converted to debug calls. Maybe we should use high priority calls (like warning) so they are displayed.


== core/bundles/linux_ubuntu_install.py ==
* Logging accepts multiline messages where the first one is the summary and the rest is a more detailed message.
* Print statements are used for installing deb packages. I am not sure if I can remove any.
** 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.
** [ES] I think if they are not used to ask for input from the user, it should be fine to replace them with debug calls. Maybe again using high priority calls so they are displayed.
 
== core/data_structures/point.py ==
* Contains print statements but should this low-level library have a dependency on core/debug?
** [DK] not sure that the dependency is a bad thing here, but show_comparison calls should probably return strings so that we can decide how to use these in GUI elements instead...
 
== gui/application_server.py ==
* Contains lots of debug print statements that might still be used?
** [ES] VisTrails server has its own logger and Phillip and I already replaced all the prints we could in the crowdlabs branch. I will merge these changes back to the master branch.

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.
Retrieved from "https://www.vistrails.org//index.php?title=Improve_error_handling/reporting&oldid=3719"