Difference between revisions of "Improve error handling/reporting"

From VistrailsWiki
Jump to navigation Jump to search
Line 12: Line 12:
== core/upgradeworkflow.py ==
== core/upgradeworkflow.py ==
* print "module %s already handled. skipping" % module_id - log or warning?
* 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?
* 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 ==
== core/analogy/__init__.py ==
*if _debug: print 'version_a:', version_a (and a lot of similar) - Is it currently being debugged? remove?
*if _debug: print 'version_a:', version_a (and a lot of similar) - Is it currently being debugged? remove?
** [DK] for now, let's keep them as low-level debug but we should be able to clean this up
== core/analogy/eigen.py ==
== core/analogy/eigen.py ==
* print m_i: remove?
* print m_i: remove?
** [DK] yeah, most of the matrix prints can be commented out or removed
== core/bundles/installbundle.py ==
== core/bundles/installbundle.py ==
* A lot of print statements are used for installing deb/rpm packages. I am not sure if I can remove any.
* A lot of print statements are used for installing deb/rpm packages. I am not sure if I can remove any.
== core/bundles/linux_ubuntu_install.py ==
== core/bundles/linux_ubuntu_install.py ==
* Print statements are used for installing deb packages. I am not sure if I can remove any.
* Print statements are used for installing deb packages. I am not sure if I can remove any.
== core/data_structures/point.py ==
== core/data_structures/point.py ==
* Contains print statements but should this low-level library have a dependency on core/debug?
* 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 ==
== gui/application_server.py ==
* Contains lots of debug print statements that might still be used?
* Contains lots of debug print statements that might still be used?

Revision as of 20:56, 15 November 2010

  • Splash screen now shows package initialization
  • Classifying log levels
    • debug 10 (cannot be accessed by setting loglevel)
    • log(info) 20
    • warning 30
    • critical 50
  • ~800 print statements in VisTrails + 200 commented ones

Conversion issues

core/upgradeworkflow.py

  • 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

  • if _debug: print 'version_a:', version_a (and a lot of similar) - Is it currently being debugged? remove?
    • [DK] for now, let's keep them as low-level debug but we should be able to clean this up

core/analogy/eigen.py

  • print m_i: remove?
    • [DK] yeah, most of the matrix prints can be commented out or removed

core/bundles/installbundle.py

  • A lot of print statements are used for installing deb/rpm packages. I am not sure if I can remove any.

core/bundles/linux_ubuntu_install.py

  • Print statements are used for installing deb packages. I am not sure if I can remove any.

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?