The difference (in my opinion) would be between

eval 1/0 # compile-time error
[download]

and

my $d= 0;
eval 1/$d;
[download]

Maybe that would be a solution to discern between compile- and runtime-errors - wrap the code in question in a subroutine. If the code compiles, then we don't have a compile-time error:

my $code;
my $ok= eval sprintf q{
    $code= sub {
        %s
    };
    1
}, $string;

if(! $ok) {
    my $err= $@;
    warn "Compile error on $string: $err";
};

$ok= eval {
    $code->();
    1;
};
if( ! $ok) {
    my $err= $@;
    warn "Runtime error on $string: $err";
};
[download]

Update: Upon testing, I now realize that 1/0 does not generate a compile-time error. But at least, that way one could find out whether there is a compile-time error or a runtime error.

In specific cases, this may work. In the generic case (I have to solve the generic case), the eval'ed code is "anything perl can offer", so may (probably will) contain dynamicly required extra code.

Above eval is implementing a try block, calling a code-ref which provided by the application.

I hope there is something indicating the state of the perl parser or the state of the VM after the eval.

Yes: I do not want to keep a table of all errors which Perl can produce... The "expected" die() messages are not under my control.

I am looking for some special variable or trick (probably other than __DIE__) to keep these three causes apart.

Can you instruct the coders that expected die messages should be prefixed (or contain) some specific piece of text. Then you only need check for that.

Perhaps, tell them that deliberate exits should be done with just die(); and look for the "Died at" text.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I tried to keep the question easy, simply stating that it should be a generic solution. The application is more complex (of course).

Log::Report is a powerful logging/exception/translation framework. It provides functions like error(), trace() and alert(), and puts them to syslog, log files, log4perl, etc. It also provides a try(). Now, the try (=eval) can catch an Log::Report::Exception object, but also texts produced by dies and croaks originating from modules which have not been implemented via the Log::Report framework. I have no control over the error message produced in CPAN modules.

Now, the try() attempts to translate these error texts into exception objects. When this exception is send to syslog (or log4perl, or ...) I want to be able to send it with the right error level. For parser errors and division by zero errors (and friends), I want to flag a more serious error-level than for "expected" errors.

The "expected" die() messages are not under my control.

:) So keep a table of messages which are under your control?

See what diagnostics does (perldiag)