The IPC::Run docs say this:

run() and finish() return TRUE when all subcommands exit with a 0 result code. ... All routines raise exceptions (via die()) when error conditions are recognized. A non-zero command result is not treated as an error condition, since some commands are tests whose results are reported in their exit codes.

Which tells me that the only thing you need to check is $?, and maybe ${^CHILD_ERROR_NATIVE} if you need to, or use the IPC::Run methods ->result or ->full_result. Since none of harness(), start(), run(), or finish() are documented to set any of $!, $^E, or $@ then checking them is likely to give you false positives - as other monks have said, a successful function call does not clear any of these variables, so the content of those variables may refer to some other operation preformed previously in the script (the exception being $? <update> by which I mean it gets set to zero after a successful system or equivalent, where the external command also returns an exit code of zero to indicate success. </update>). As a general rule, the Error Variables should only be considered to be valid immediately after the failed function call that is documented to set them - note how one writes open(...) or die "Error: $!", i.e. $! is only valid when open returns false. Note how the value of $! is useless after the second (successful) open:

use warnings;
use strict;
open my $fh1, '<', '/thisfiledoesntexist'; warn $!;
open my $fh2, '<', '/etc/passwd'; warn $!;
my @lines = <$fh2>;
print "Read ",0+@lines," lines\n";

__END__

No such file or directory at - line 3.
Inappropriate ioctl for device at - line 4.
Read 45 lines
[download]

when I try to check $! and $^E, I get 'Illegal seek'.

The problem with checking those error variables is that they are set by low-level operations, not the high level ones you are using.

For example: The "Illegal Seek" message can mean that a repetitive Next File or similar operation has nothing more to return. The error makes sense in the context of the low-level seek operation, but not in the higher level Find All, where it simply means: You've got them all.

Context is everything, and unless the module author has done a very thorough job, they will often make no sense in terms of the higher level code you are using.

"... like using IPC::Run...robust mechanism for catching error info..."

Perhaps this node might be inspirating: Re: Using IPC::Open3 instead of backtick operator.

Regards, Karl