1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
Source: liblexical-failure-perl
Section: perl
Priority: optional
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Uploaders: Salvatore Bonaccorso <carnil@debian.org>
Build-Depends: debhelper (>= 8)
Build-Depends-Indep: libkeyword-simple-perl,
libscope-upper-perl,
libtest-effects-perl,
perl (>= 5.14.0)
Standards-Version: 3.9.6
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-perl/packages/liblexical-failure-perl.git
Vcs-Git: git://anonscm.debian.org/pkg-perl/packages/liblexical-failure-perl.git
Homepage: https://metacpan.org/release/Lexical-Failure
Testsuite: autopkgtest-pkg-perl
Package: liblexical-failure-perl
Architecture: all
Depends: ${misc:Depends}, ${perl:Depends},
libkeyword-simple-perl,
libscope-upper-perl,
perl (>= 5.14.0)
Description: Perl module for user-selectable lexically-scoped failure signaling
Lexical::Failure sets up two new keywords: fail and ON_FAILURE, with which
you can quickly create modules whose failure signaling is lexcially scoped,
under the control of client code.
.
Normally, modules specify some fixed mechanism for error handling and require
client code to adapt to that policy. One module may signal errors by
returning undef, or perhaps some special "error object". Another may die or
croak on failure. A third may set a flag variable. A fourth may require the
client code to set up a callback, which is executed on failure.
.
If you are using all four modules, your own code now has to check for failure
in four different ways, depending on where the failing component originated.
If you would rather that all components throw exceptions, or all return
undef, you will probably have to write wrappers around 3/4 of them, to
convert from their "native" failure mechanism to your preferred one.
|
