Alex,
The the reason we don't want to handle errors that were throw in eval blocks is the reason you mentioned. Typically, the user handles the error themself. But it is bad that $@ refers to exception_handler.pm line 34 after a die. I think we can fix this somehow.
Try the attached exception_handler.pm.
I only changed 'sub die'.
perl example:
__________ #!/usr/bin/perl $a = 5; $b = -1; #open (F, '/t/t') || die "Can't find file and program exits!"; eval { $c = $a / $b; die "Denominator cannot be negative" if ($b < 0); };
print "eval exception is printed and program runs further"; _____________
Now if you uncomment open (F, ...
the program will stop with the exception message at line 4
If you disable open(F, ... again
the program will run through the eval block, will print the exception message, AND will run further to the end.
Also, for things that are errors, they should be written to TM_ERROR_FD. Something written to STDERR that isn't an error should be left alone. Would it be possible to filter STDERR from a perl module that we can load using the -m switch?
???Well, if you are using the switch -w or -W or the statement warn() perl will also output warnings at STDERR. So, to distinguish between a real error and warnings is a bit tricky. A very quick and dirty solution for that would be to run the perl script with the switch -c first to check whether the syntax is ok and after that execute this script. If the syntax is ok everything is written to STDERR should be 'only' warnings. Otherwise if the syntax check is not ok this output should go to TM_ERROR_FD. At least this is my first thought. Tomorrow I will see whether I find an other solution.
Best,
Hans
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.