← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/trace.py

  • Committer: John Arbash Meinel
  • Date: 2010-01-06 17:46:15 UTC
  • mto: (4634.119.1 2.0)
  • mto: This revision was merged to the branch mainline in revision 4951.
  • Revision ID: john@arbash-meinel.com-20100106174615-cq1nckxhbuyemgjx
https://launchpad.net/bugs/503886
Fix bug #503886, errors setting up logging go to stderr.

The basic issue is that we were using logging to describe failures
to set up logging. However, those fail with bad error messages
rather than giving us the output we want. This was especially bad
when the failure was occuring on the server. Since 'ssh' will pass
back the stderr stream without bzr handling it at all.

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/trace.py
237
237
            bzr_log_file.write("bug reports to https://bugs.launchpad.net/bzr/+filebug\n\n")
238
238
        return bzr_log_file
239
239
    except IOError, e:
240
 
        warning("failed to open trace file: %s" % (e))
 
240
        # If we are failing to open the log, then most likely logging has not
 
241
        # been set up yet. So we just write to stderr rather than using
 
242
        # 'warning()'. If we using warning(), users get the unhelpful 'no
 
243
        # handlers registered for "bzr"' when something goes wrong on the
 
244
        # server. (bug #503886)
 
245
        sys.stderr.write("failed to open trace file: %s\n" % (e,))
241
246
    # TODO: What should happen if we fail to open the trace file?  Maybe the
242
247
    # objects should be pointed at /dev/null or the equivalent?  Currently
243
248
    # returns None which will cause failures later.