Difference between revisions of "Improve error handling/reporting"

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


= 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 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] Why not? I couldn't see any problem.
 
== 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"