Muppet <[EMAIL PROTECTED]> writes:
>> Muppet wrote:
>>
>>> third, that's not a very perlish failure. wouldn't it make more
>>> sense to croak() on that error? e.g.:
>>>
>>> if (! foo (x))
>>> croak ("Wrong parameter %d", x); /* does not return */
>>>
>> 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
>> 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]
> }
And note that _ALL_ perl/Tk callbacks are effectively inside an eval {}.
You have a choice of handler - either write to
console or a popup with the error message. Neither kills the app,
but that can be re-instated if you want to ...
>
>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.)
