> sub new {
>
> my $pkg = shift;
> my $fdatref = shift;
> my $database = 'patients';
> my $obj = bless {
> '_fdatref' => $fdatref,
> '_balances' => 0, ## array ref for balances
> '_prev_patnums' => 0, ## array ref for prev_patnums
> '_dbh' => SQLHANDLE->allocate($database)
> }, $pkg;
> return $obj;
> }
One problem could be, if SQLHANDLE->allocate dies (e.g. in getdbh), then
your object will never returned and will be undef in further [- -] blocks
You can wrap your constructor in an eval { } to catch this case.
>
> Yes. In order to spare you too much code, I forgot to mention that we
> have rewritten the
> code to be
> [- use FINANCEMOD -]
>
> and this fails to take in the module. It ends with a return 1
> statement.
>
>
> I run into this often.
>
this is converted by Embperl internaly to
$x = eval { sub { use FINANCEMOD ; } } ;
I have seen this problem seen before, seems like Perl requires the semicolon
in this case.
>
> > >From point of scoping [- -] is wrapped in an Perl { } block,
>
> Does that mean the entire pages embperl is evaluated together as one
> eval?
>
each [- -] is evaled as a separate anoymous sub, if there are any [* *]
blocks they are evaled in one sub together, which calls the other subs, but
this are the current implementation details, which may change in the future
(e.g. in Embperl 2.0). Anyway I will make sure that scoping remains the
same.
> We call a CGI from modules from EMBPERL all under mod_perl. When we run
> into
> this bug, it seems to happen after [$ $] if or whiles or foreaches.
> I've also wondered
> about $escmod - it might be adding to the trouble as we are changing it
> from section to selection.
>
This shouldn't be a problem.
Gerald
