|Version 8 (modified by 9 years ago) ( diff ),|
Custom Trac Exceptions
Trac defines a set of custom exception types:
TracBaseError(trac.core): Exception base class for errors in Trac.
TracError(trac.core): Standard Exception for errors in Trac.
AdminCommandError(trac.admin.api): Exception raised when an admin command cannot be executed.
ConfigurationError(trac.config): Exception raised when a value in the configuration file is not valid.
InvalidAttachment(trac.attachment): Exception raised when attachment validation fails.
InvalidTicket(trac.ticket.web_ui): Exception raised when a ticket fails validation.
InvalidWikiPage(trac.wiki.web_ui): Exception raised when a Wiki page fails validation. Not used anymore since 0.11
QuerySyntaxError(trac.ticket.query): Exception raised when a ticket query cannot be parsed from a string.
QueryValueError(trac.ticket.query): Exception raised when a ticket query has bad constraint values.
ResourceNotFound(trac.resource): Thrown when a non-existent resource is requested
TimeoutError(trac.db.pool): Exception raised by the connection pool when no connection has become available after a given timeout (Prior to 1.0.2dev-r12305, inherited directly from
HTTPException(trac.web.api): Representing a HTTP status code
RequestDone(trac.web.api): Marker exception that indicates whether request processing has completed and a response was sent.
ParseError(trac.versioncontrol.svn_authz): Exception thrown for parse errors in authz files
Hierarchy is inconsistent, even after addition of
TracBaseError class (#11568). There doesn't seem to be any consistent pattern in inheriting from
TracError. Some exceptions also inherit from built-in exception classes other than
There also seem to be multiple naming conventions. Consider following PEP:0008#exception-names.
But changing the existing hierarchy might be difficult without breaking backward compatibility.
try: with env.db_transaction as db: ... except env.db_exc.IntegrityError, e: ...
The above example catches
depending on the selected DatabaseBackend.