Difference between revisions of "Improve error handling/reporting"

From VistrailsWiki
Jump to navigation Jump to search
Line 35: Line 35:
* 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...
** [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...
[TE] show_comparison functions occurs in more places but seems to only be used when debugging. They don't seem to have any value to a normal user and can probably be left as they are.
** [TE] show_comparison functions occurs in more places but seems to only be used when debugging. They don't seem to have any value to a normal user and can probably be left as they are.


== 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?
** [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.
** [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.
[TE] OK
** [TE] OK

Revision as of 16:34, 16 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.
    • [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

  • Print statements are used for installing deb packages. I am not sure if I can remove any.
    • [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...
    • [TE] show_comparison functions occurs in more places but seems to only be used when debugging. They don't seem to have any value to a normal user and can probably be left as they are.

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.
    • [TE] OK