Re: Finding out whether a module contains a certain package

If you simply want to terminate with an exception, why not wrap the calls to Class::MixinFactory with an eval block. Maybe something like this (psuedocode)?

sub makeMixin {
  #input is an array of file names
  my @aImpliedPackageNames = map { ... } @_;

  my $class;
  eval {
    $class = MyClass->class(@aImpliedPackageNames);
    return 1;
  } or do {
     my $e=$@;
     # compute exception of your choosing, e.g.
     # a list of missing modules:

     my @aNotFound;
     foreach my $sPackage (@aImpliedPackageNames) {
       if (!eval("scalar keys %${sPackage}::")) {
          push @aNotFound, $sPackage;
       }
     }

     if (scalar(@aNotFound)) {
        die "Couldn't make mixin: the following packages "
            . "are undefined: @aNotFound";
     } else {
        die $e;
     }
  }
  return $class;
}
[download]

Best, beth

Comment on Re: Finding out whether a module contains a certain package Download Code

Replies are listed 'Best First'.
Re^2: Finding out whether a module contains a certain package by rovf (Priest) on May 05, 2009 at 07:34 UTC
That's what is done anyway, but since MixinFactory does not throw an exception in this case, the eval block is of no use. Also, I don't want to terminate. If I would want to terminate, I just could leave it as it is. -- Ronald Fischer <ynnor@mm.st>	[reply]
Re^3: Finding out whether a module contains a certain package by ELISHEVA (Prior) on May 05, 2009 at 08:51 UTC
If your program is really terminating, are you sure you are even finishing compilation? eval doesn't need one to throw an explicit exception or even a die statement in the enclosed code. The only thing it won't "catch" is an explicit exit statement buried somewhere in the enclosed code. Do you mean to say that Class::MixinFactory is calling exit? I searched Class::MixinFactory::Factory where the `class(...)` subroutine is defined and could find no such call. Consider these two examples. The first terminates because of division by 0, but the second does not. Neither throw exceptions. First example using a hard-coded division by 0 (compilation error before we even get to eval) `sub foo { 5/0; } print "Before foo\n"; eval { foo 0; return 1; } or do { print "Oops!\n" }; print "Going onto other things\n"; # output Illegal division by zero at ...` [download] Second example using a variable denominator (runtime error) `sub foo { 5/$_[0]; } print "Before foo\n"; eval { foo 0; return 1; } or do { print "Oops!\n" }; print "Going onto other things\n"; #outputs Before foo Oops! Going onto other things` [download] But even if `eval { ... }` doesn't work, you could still scan the symbol table for the packages involved in the mix-in after you call `class(...)` and then throw your own exception if you don't like what you see, i.e. `if (scalar @aNotFound) { die ... }`. I'm sure you've already thought of that, so perhaps you could explain why that doesn't work for you? Best, beth Update: clarification of timing of compilation error.	[reply] [d/l] [select]
Re^4: Finding out whether a module contains a certain package by rovf (Priest) on May 05, 2009 at 11:38 UTC
Your example does not apply in my case, because in your case, the program would not even start to run. My problem applies to a program, which is already running (i.e. already produced output). When eval finds a syntax error during compile, eval says: If there is a syntax error ..., an undefined value is returned by "eval", and $@ is set to the error message. Incidentally, when rechecking my code, I indeed found a bug, in that I don't properly handle the case when eval returns undef, so maybe this explains what I have seen: eval does return, but returns undef, and my program crashes when it uses that undef value. I will fix this, to be on the safe side. -- Ronald Fischer <ynnor@mm.st>	[reply]