|Do you know where your variables are?|
I think what was meant is that exit() sometimes can prevent syntactically (correct) code from being executed. It is also true that sometimes it does not. Human language can be frustratingly ambiguous and imprecise: the quoted statement could have implied sometimes but not all, or it could have been intended to mean all.
One can gain a few Karma points on PerlMonks here and there by finding mistakes, possibly by a imposing a slightly different or more rigourous interpretation, and possibly attached to side points. Where it to be so easy to reach true Nirvana that way.
What I have been seeking a deeper understanding what is going on inside Perl and perl -c with the hope to coming to a simpler, more reliable means to test whether a string is a Perl statement or expression. After all, eval() has to go through a syntax check its course its existance. If this question has been asked several times before and the best that had been suggested has been perl-c (which is really not that bad or the end of the world), then I think we can do very small bit better by creating a simple Syntax::Check module. That this might be of help to the broader community is more important to me than the PerlMonks Karma points in correcting someone here or there.
I am also optimistic that there might (one day) be a way to just ask Perl to do syntax check part that it does for eval() without the evaluation part.
With all of this behind, it has become clear that yet again, I have not fully explained my situtation and the problem I'm trying to solve.
I really do want to just check whether something is syntactically correct. No evaluation should be done. Therefore solutions with eval() which can have side effects are probably not good. And devilish kinds of expressions and Perl programs probably also have to be properly handled
So let me make try to again to explain this in a very specific setting without trying generalize. In contrast to the stock Perl debugger perl5db, Devel::Trepan has a front-end program called trepan.pl that does the setup for Perl debugger invocation. This allows one to specify simple debugger options like whether terminal highlighting is desired. But before trepan.pl takes the plunge into exec to reinvoke Perl with the appropriate flags, it checks to see if the eval string or Perl program is valid. That way it can report back a more reasonable and controllable error message.
There are a couple of other situations where syntax-only checking is needed. Breakpoints can have conditional expressions associated with them that determine whether to respect or ignore the breakpoint. These expression are evaluated in a context that can be totally different from the context inside the debugger where a programmer specifies what to test for. So an eval inside the debugger of say $a may result in an unbound variable, whereas at the point a breakpoint occurs that variable may be defined and have a value. Similarly, one can ask the debugger to run specific Perl statements in the context of the current stopping point of the program. In gdb terms these are called display expressions. In perl5db, they are called actions.