With error handling, I think your best option may be to execute your perl code within a eval statement and examine the value of $@ upon exit from the scope. I would suggest you to have a read through "Error Indicators", also on the perlvar page (right down the bottom).

Ooohhh, Rob no beer function well without!

1. using pipe() twice
2. fork()'ing off a child.
3. Using open() in the child to reset STDOUT and STDERR to the writing ends of the pipes.
4. using exec() in the child to start the command
5. let the parent (from the fork()) read the other ends of the pipes, and process them seperatly.

In Perl, exceptions can be generated by using die(). These 'die exceptions' can be caught by enclosing them to eval{}. It works much like Java's throw/catch system.

But nothing enforces any standard nor strong convention on how object thrown by die() has to look like. Most implementations (and perl core too) dies with plain string. Only way to evaluate such an exception is pattern match on $@ after eval. This looks quite cumbersome to me. But there is some light at the end of a tunnel, for example Exception module from CPAN.

But ... even if this worked just like it works in Java, vast majority of modules does not use this mechanism. It is not Perl programmer's 'common sense' to use exceptions. Many of intermediate Perl coders even doesn't know that any way to use exceptions exists in perl.

Back to your original question: forget the exceptions if you want to use a module. Look at STDERR redirection as the other repries indicated. Check the error codes. Alternatively, you may encloce module call to eval { call_here() };, but this will not stop module writing to STDERR, it only catches die() conditions.

Another option could be __WARN__ handler. If the module you are using uses warn() to print to STDERR, you may use $SIG{__WARN__} = \&logging_routine; to catch the warnings.

my $errorCode = system(SYSCOMMAND/SCRIPT);
[download]

my $errorMessage = `SYSCOMMAND/SCRIPT`;   # back ticks
[download]