← Back to branch summary

~jameinel/bzr/fix-push2

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Martin Pool
  • Date: 2006-11-03 01:52:12 UTC
  • mto: This revision was merged to the branch mainline in revision 2119.
  • Revision ID: mbp@sourcefrog.net-20061103015212-1e5f881c2152d79f
Review comments

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
439
439
 
440
440
Errors are handled through Python exceptions.
441
441
 
442
 
We broadly classify errors as either being either the user's fault or our
443
 
fault.  If we think it's our fault, we show a backtrace, an invitation to
444
 
report the bug, and possibly other details.  This is the default for
445
 
errors that aren't specifically recognized as being caused by a user
446
 
error.
447
 
 
448
 
User errors are things such as referring to a file or location that
449
 
doesn't exist.  The user could potentially fix them themselves, so they
450
 
get a short but helpful message.  User errors either have the
451
 
``is_user_error`` property set, or are of particular classes such as
452
 
KeyboardInterrupt.
 
442
We broadly classify errors as either being either internal or not,
 
443
depending on whether ``user_error`` is set or not.  If we think it's our
 
444
fault, we show a backtrace, an invitation to report the bug, and possibly
 
445
other details.  This is the default for errors that aren't specifically
 
446
recognized as being caused by a user error.  Otherwise we show a briefer
 
447
message, unless -Derror was given.
453
448
 
454
449
Many errors originate as "environmental errors" which are raised by Python
455
450
or builtin libraries -- for example IOError.  These are treated as being
473
468
format string.
474
469
 
475
470
Exception strings should start with a capital letter and should not have a
476
 
final fullstop.
 
471
final fullstop.  If long, they may contain newlines to break the text.
477
472
 
478
473
 
479
474