Hello Nick,
Nick Ing-Simmons wrote:

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 ...


Thank you, it seems to me at a good error handling. Not in all cases, because sometimes, if an error occure, i want to continue
the file parsing but having also a _error_ message back from my XSub, to know there was something wrong in the structure of the file.
I changed my XSubs and methods in this way.


An other question: if I do a croak() on error what is the return code of the XSub?
e.g. for this
int _get_afpds_mode(IN sv_hFile, OUT mode, OUT rclength, perror)
...
PREINIT:
....
CODE:
{
if(!sv_hFile)
croak("no sv_hFile !");
}



mit freundlichen GrÃÃen, with my best regards, Reinhard




Reply via email to