Skip Menu |

This queue is for tickets about the Devel-EvalError CPAN distribution.

Report information
The Basics
Id: 51860
Status: new
Priority: 0/
Queue: Devel-EvalError

People
Owner: Nobody in particular
Requestors: FWIE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.001002
Fixed in: (no value)



Subject: [Patch] POD nits
The attached patch fixes some POD, which renders wrong, at least at search.cpan.org.
Subject: pod.patch
diff --git a/EvalError.pm b/EvalError.pm index fad40b3..84fa7c4 100644 --- a/EvalError.pm +++ b/EvalError.pm @@ -263,7 +263,7 @@ Then you should replace it with code more like this: =head2 Caveats -It is important to call C<Devel::EvalError->new()> before doing the C<eval>. +It is important to call C<< Devel::EvalError->new() >> before doing the C<eval>. Although I believe that in all existing implementations of Perl v5, the following code still works, there is no iron-clad guarantee that it will do things in the required order (such as in some future version of Perl). So @@ -527,7 +527,7 @@ the first one gets destroyed. The lifetimes of C<Devel::EvalError> objects must be strictly nested or else they can't properly deal with sharing the single global C<$SIG{__DIE__}> slot. -Calling C<$ee->Reuse();> ensures that the previous object gets cleaned up +Calling C<< $ee->Reuse(); >> ensures that the previous object gets cleaned up I<before> the next one is initialized, preventing such noisy problems. Note that C<Reuse()> returns the invoking object so that you can choose