On Dec 6, 2004, at 8:27 AM, Reinhard Pagitsch wrote:
Hello Muppet,
Muppet wrote:
third, that's not a very perlish failure. wouldn't it make more sense to croak() on that error? e.g.:Hmm, on my understanding is that croak writes only to the console and do a exit to my perl module? But I want to have the error message back in my module, where
if (! foo (x)) croak ("Wrong parameter %d", x); /* does not return */
I can handle it propper. e.g. write a message in the status line of a Tk GUI from which the module was called.
I am wrong with that?
not exactly. croak() is the way to throw exceptions in perl. if you don't handle the exception, yes, it will print to the console and die. but if you wrap the calling block in eval(), you'll trap the exception, and get the error message back in [EMAIL PROTECTED] (you can even use exception objects...)
eval {
call_some_function_that_might_croak ();
call_something_else_that_might_die ();
};
if ($@) {
# the error message is in [EMAIL PROTECTED]
}this construct is handy because it allows you to avoid lots of tedious and ugly error-return checking -- if call_some_function_that_might_croak() croaks, control will jump immediately out of the eval() block without executing any further statements inside.
(the perl manpages describe all this, but i can't remember which ones at the moment. try perldoc -f for eval, croak, and die.)
--
How come hair colors for women take an hour, but "wash out the gray" stuff for men only five minutes? This is so unfair!
-- Elysse, complaining about commercials
