Logo Search packages:      
Sourcecode: paste version File versions  Download package

paste::exceptions::collector::ExceptionCollector Class Reference

List of all members.


Detailed Description

Produces a data structure that can be used by formatters to
display exception reports.

Magic variables:

If you define one of these variables in your local scope, you can
add information to tracebacks that happen in that context.  This
allows applications to add all sorts of extra information about
the context of the error, including URLs, environmental variables,
users, hostnames, etc.  These are the variables we look for:

``__traceback_supplement__``:
    You can define this locally or globally (unlike all the other
    variables, which must be defined locally).

    ``__traceback_supplement__`` is a tuple of ``(factory, arg1,
    arg2...)``.  When there is an exception, ``factory(arg1, arg2,
    ...)`` is called, and the resulting object is inspected for
    supplemental information.

``__traceback_info__``:
    This information is added to the traceback, usually fairly
    literally.

``__traceback_hide__``:
    If set and true, this indicates that the frame should be
    hidden from abbreviated tracebacks.  This way you can hide
    some of the complexity of the larger framework and let the
    user focus on their own errors.

    By setting it to ``'before'``, all frames before this one will
    be thrown away.  By setting it to ``'after'`` then all frames
    after this will be thrown away until ``'reset'`` is found.  In
    each case the frame where it is set is included, unless you
    append ``'_and_this'`` to the value (e.g.,
    ``'before_and_this'``).

    Note that formatters will ignore this entirely if the frame
    that contains the error wouldn't normally be shown according
    to these rules.

``__traceback_reporter__``:
    This should be a reporter object (see the reporter module),
    or a list/tuple of reporter objects.  All reporters found this
    way will be given the exception, innermost first.

The actually interpretation of these values is largely up to the
reporters and formatters.

``collect_exception(*sys.exc_info())`` will return an object with
several attributes:

``frames``:
    A list of frames
``exception_formatted``:
    The formatted exception, generally a full traceback
``exception_type``:
    The type of the exception, like ``ValueError``
``exception_value``:
    The string value of the exception, like ``'x not in list'``
``identification_code``:
    A hash of the exception data meant to identify the general
    exception, so that it shares this code with other exceptions
    that derive from the same problem.  The code is a hash of
    all the module names and function names in the traceback,
    plus exception_type.  This should be shown to users so they
    can refer to the exception later. (@@: should it include a
    portion that allows identification of the specific instance
    of the exception as well?)
    
The list of frames goes innermost first.  Each frame has these
attributes; some values may be None if they could not be
determined.

``modname``:
    the name of the module
``filename``:
    the filename of the module
``lineno``:
    the line of the error
``revision``:
    the contents of __version__ or __revision__
``name``:
    the function name
``supplement``:
    an object created from ``__traceback_supplement__``
``supplement_exception``:
    a simple traceback of any exception ``__traceback_supplement__``
    created
``traceback_info``:
    the str() of any ``__traceback_info__`` variable found in the local
    scope (@@: should it str()-ify it or not?)
``traceback_hide``:
    the value of any ``__traceback_hide__`` variable
``traceback_log``:
    the value of any ``__traceback_log__`` variable


``__traceback_supplement__`` is thrown away, but a fixed
set of attributes are captured; each of these attributes is
optional.

``object``:
    the name of the object being visited
``source_url``:
    the original URL requested
``line``:
    the line of source being executed (for interpreters, like ZPT)
``column``:
    the column of source being executed
``expression``:
    the expression being evaluated (also for interpreters)
``warnings``:
    a list of (string) warnings to be displayed
``getInfo``:
    a function/method that takes no arguments, and returns a string
    describing any extra information
``extraData``:
    a function/method that takes no arguments, and returns a
    dictionary.  The contents of this dictionary will not be
    displayed in the context of the traceback, but globally for
    the exception.  Results will be grouped by the keys in the
    dictionaries (which also serve as titles).  The keys can also
    be tuples of (importance, title); in this case the importance
    should be ``important`` (shows up at top), ``normal`` (shows
    up somewhere; unspecified), ``supplemental`` (shows up at
    bottom), or ``extra`` (shows up hidden or not at all).

These are used to create an object with attributes of the same
names (``getInfo`` becomes a string attribute, not a method).
``__traceback_supplement__`` implementations should be careful to
produce values that are relatively static and unlikely to cause
further errors in the reporting system -- any complex
introspection should go in ``getInfo()`` and should ultimately
return a string.

Note that all attributes are optional, and under certain
circumstances may be None or may not exist at all -- the collector
can only do a best effort, but must avoid creating any exceptions
itself.

Formatters may want to use ``__traceback_hide__`` as a hint to
hide frames that are part of the 'framework' or underlying system.
There are a variety of rules about special values for this
variables that formatters should be aware of.

TODO:

More attributes in __traceback_supplement__?  Maybe an attribute
that gives a list of local variables that should also be
collected?  Also, attributes that would be explicitly meant for
the entire request, not just a single frame.  Right now some of
the fixed set of attributes (e.g., source_url) are meant for this
use, but there's no explicit way for the supplement to indicate
new values, e.g., logged-in user, HTTP referrer, environment, etc.
Also, the attributes that do exist are Zope/Web oriented.

More information on frames?  cgitb, for instance, produces
extensive information on local variables.  There exists the
possibility that getting this information may cause side effects,
which can make debugging more difficult; but it also provides
fodder for post-mortem debugging.  However, the collector is not
meant to be configurable, but to capture everything it can and let
the formatters be configurable.  Maybe this would have to be a
configuration value, or maybe it could be indicated by another
magical variable (which would probably mean 'show all local
variables below this frame')

Definition at line 38 of file collector.py.


Public Member Functions

def __init__
def collectException
def collectExceptionOnly
def collectLine
def collectSupplement
def getLimit
def getRevision

Public Attributes

 limit

Static Public Attributes

int show_revisions = 0

The documentation for this class was generated from the following file:

Generated by  Doxygen 1.6.0   Back to index