The <B>Tk::ErrorB> method is invoked by perl/Tk when a background
error occurs. Two possible implementations are provided in the
distribution and individual applications or users can (re)define a <B>Tk::ErrorB>
method (e.g. as a perl sub) if they wish to handle background
errors in some other manner.
A background error is one that occurs in a command that didnt
originate with the application. For example, if an error occurs
while executing a callback specified with a
bind or a after
command, then it is a background error. For a non-background error,
the error can simply be returned up through nested subroutines
until it reaches the top-level code in the application;
then the application can report the error in whatever way it
wishes. When a background error occurs, the unwinding ends in
the Tk library and there is no obvious way for Tk to report
When Tk detects a background error, it saves information about the
error and invokes the <B>Tk::ErrorB> method later when Tk is idle.
<B>Tk::ErrorB> is invoked by perl/Tk as if by the perl code:
$mainwindow-><B>Tk::ErrorB>(error message, location ...);
$mainwindow is the <B>MainWindowB> associated with widget which
detected the error, error message is a string describing the error
that has been detected, location is a list of one or more locations
which describe the call sequence at the point the error was detected.
The locations are a typically a mixture of perl location reports giving
script name and line number, and simple strings describing locations in
core Tk or perl/Tk C code.
Tk will ignore any result returned by the <B>Tk::ErrorB> method.
If another error occurs within the <B>Tk::ErrorB> method
(for example if it calls <B>dieB>) then Tk reports this error
itself by writing a message to stderr (this is to avoid infinite loops
due to any bugs in <B>Tk::ErrorB>).
If several background errors accumulate before <B>Tk::ErrorB>
is invoked to process them, <B>Tk::ErrorB> will be invoked once
for each error, in the order they occurred.
However, if <B>Tk::ErrorB> calls <B>Tk->breakB>, then
any remaining errors are skipped without calling <B>Tk::ErrorB>.
The <B>TkB> module includes a default <B>Tk::ErrorB> subroutine
that simply reports the error on stderr.
An alternate definition is provided via:
that posts a dialog box containing the error message and offers
the user a chance to see a stack trace showing where the
This is an OO implementation of the Tcl/Tk command <B>bgerrorB>, with a
twist: since there is only one <B>ErrorDialogB> widget, you arent required
to invoke the constructor to create it; it will be created
automatically when the first background error occurs. However, in
order to configure the -cleanupcode and -appendtraceback
<B>ErrorDialogB> options you must call the constructor and create it
The <B>ErrorDialogB> object essentially consists of two subwidgets: a
<B>DialogB> widget to display the background error and a <B>TextB> widget
for the traceback information. If required, you can invoke various
widget methods to customize these subwidgets - their advertised names
are described below.
$mw-><B>ErrorDialogB>(-cleanupcode => code, -appendtraceback => bool);
$mw is a window reference.
code is a CODE reference if special post-background error
processing is required (default is undefined). The callback subroutine
is called with @_ having the same arguments that <B>Tk::ErrorB> was
bool is a boolean indicating whether or not to append successive
tracebacks (default is 1, do append).