view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    deeper frames.

SEE ALSO
    The Callback::Frame github repo
    <https://github.com/hoytech/Callback-Frame>

    AnyEvent::Task uses Callback::Frame and its docs have more discussion on
    exception handling in async apps.

    This module's "catch" syntax is of course modeled after "normal
    language" style exception handling as implemented by Try::Tiny and
    similar.

    This module depends on Guard to maintain the
    $Callback::Frame::active_frames datastructure and to ensure that "local"
    binding updates aren't lost even when exceptions or other non-local
    returns occur.

    AnyEvent::Debug provides an interactive debugger for AnyEvent
    applications and uses some of the same techniques that Callback::Frame
    does. AnyEvent::Callback and AnyEvent::CallbackStack sort of solve the

lib/Callback/Frame.pm  view on Meta::CPAN

Objects stored in local bindings managed by Callback::Frame will not be destroyed until all references to the frame-wrapped callback that contains the binding are destroyed, along with all references to any deeper frames.



=head1 SEE ALSO

L<The Callback::Frame github repo|https://github.com/hoytech/Callback-Frame>

L<AnyEvent::Task> uses Callback::Frame and its docs have more discussion on exception handling in async apps.

This module's C<catch> syntax is of course modeled after "normal language" style exception handling as implemented by L<Try::Tiny> and similar.

This module depends on L<Guard> to maintain the C<$Callback::Frame::active_frames> datastructure and to ensure that C<local> binding updates aren't lost even when exceptions or other non-local returns occur.

L<AnyEvent::Debug> provides an interactive debugger for AnyEvent applications and uses some of the same techniques that Callback::Frame does. L<AnyEvent::Callback> and L<AnyEvent::CallbackStack> sort of solve the dynamic error handler problem. Unlike...

L<Promises> and L<Future> are similar modules but they solve a slightly different problem. In the area of exception handling they require a more drastic restructuring of your async code because you need to pass "promise/future" objects around to main...

Miscellaneous other modules: L<IO::Lambda::Backtrace>, L<POE::Filter::ErrorProof>

Python Tornado's L<StackContext|http://www.tornadoweb.org/en/branch2.3/stack_context.html> and C<async_callback>