VisTrails Home

Improve error handling/reporting

From VisTrailsWiki

(Difference between revisions)
Jump to: navigation, search
(core/bundles/installbundle.py)
 
(5 intermediate revisions 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.
-
 
+
-
== 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.
+

Current revision as of 13: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.
Personal tools