~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2006-11-03 02:35:48 UTC
  • mfrom: (2067.3.7 cleanup-errors)
  • Revision ID: pqm@pqm.ubuntu.com-20061103023548-12e702bb911c4be2
(mbp) deprecate BzrNewError, change to using .internal_error on exceptions, etc

Show diffs side-by-side

added added

removed removed

Lines of Context:
437
437
Errors and exceptions
438
438
=====================
439
439
 
440
 
Errors are handled through Python exceptions.  They can represent user
441
 
errors, environmental errors or program bugs.  Sometimes we can't be sure
442
 
at the time it's raised which case applies.  See bzrlib/errors.py for 
443
 
details on the error-handling practices.
 
440
Errors are handled through Python exceptions.
 
441
 
 
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.
 
448
 
 
449
Many errors originate as "environmental errors" which are raised by Python
 
450
or builtin libraries -- for example IOError.  These are treated as being
 
451
our fault, unless they're caught in a particular tight scope where we know
 
452
that they indicate a user errors.  For example if the repository format
 
453
is not found, the user probably gave the wrong path or URL.  But if one of
 
454
the files inside the repository is not found, then it's our fault --
 
455
either there's a bug in bzr, or something complicated has gone wrong in
 
456
the environment that means one internal file was deleted.
 
457
 
 
458
Many errors are defined in ``bzrlib/errors.py`` but it's OK for new errors
 
459
to be added near the place where they are used.
 
460
 
 
461
Exceptions are formatted for the user by conversion to a string
 
462
(eventually calling their ``__str__`` method.)  As a convenience the
 
463
``._fmt`` member can be used as a template which will be mapped to the
 
464
error's instance dict.
 
465
 
 
466
New exception classes should be defined when callers might want to catch
 
467
that exception specifically, or when it needs a substantially different
 
468
format string.
 
469
 
 
470
Exception strings should start with a capital letter and should not have a
 
471
final fullstop.  If long, they may contain newlines to break the text.
 
472
 
444
473
 
445
474
 
446
475
Jargon