Re^2: Bad File Descriptor Error

Thanks for taking the time to explain my misunderstanding so clearly. I am writing more apps that run in environments outside of my control, so I am trying to make the error handling more robust. My understanding of using eval in this way is that it will trap errors that may be fatal, but allow me to handle them gracefully if possible. After re-reading the perldoc for eval, I see, as you said, that I have to check $@ for error messages.

If I am misusing eval in this context, I would appreciate any pointers.

Thanks again
digger

Comment on Re^2: Bad File Descriptor Error

Replies are listed 'Best First'.
Re^3: Bad File Descriptor Error by Bro. Doug (Monk) on Mar 20, 2007 at 18:26 UTC
These are just a couple of warnings for you (hopefully, you'll find this advice irrelevant ). I've run into problems with $@ on -some- Windows systems. However, you can always use $EVAL_ERROR ( $@ is shorthand for this ). I don't know where this bug comes from, sorry. Also, on the Emachine T2862 (and only this model, in my experience), I've had problems with: `print HANDLE $stuff ; # doesn't seem to work on T2862` [download] Hopefully, you're not dealing with one of those. Good luck. Bro. Doug :wq	[reply] [d/l]
Re^3: Bad File Descriptor Error by Anno (Deacon) on Mar 20, 2007 at 14:58 UTC
Your `eval()` makes sense if `Win32::CopyFile()` throws exceptions at run time and you want to deal with that. I don't know if it does. The pure Perl operation `$dest = $$appconfig{"destination"}."\\$filename";` [download] does not belong there. If there was a fatal error in that line, it would be a program error and you'd have to correct the line. It doesn't make sense to catch programming errors in `eval()`. Anno	[reply] [d/l] [select]