You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/01/23 02:56:11 UTC
Re: cvs commit: modperl-2.0 Changes
> #test adding config at request time
> - my $errmsg = $r->add_config(['require valid-user']);
> - die $errmsg if $errmsg;
> + $r->add_config(['require valid-user']);
I don't know about this. I was going to work up my thoughts as a result of
another thread, but I might as well do so here...
I think it's a bad practice for a persistent OO interface to die at runtime.
what you've done means that I need to now use eval() logic to handle the
exception, rather than simply checking the return value - several extra
lines of code (and processing) when 1 will do just fine. and it further
obscures our interface: which methods do I need to trap with eval() and
which can I trust not to die again?
I think it's ok to die at startup or something, but if your request-time
handler dies request after request because of, say, a different
AllowOverrides config, it's bad. I've followed this rule in my own
persistent environments (not only mod_perl :) and found it really to be a
best practice.
so, I'd suggest re-thinking this a bit. I understand what you were trying
to solve, but maybe there is another way? maybe call croak on
$s->add_config but not $r->add_config?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0 Changes
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>1. returning an error message is not perlish. it should be then
>>intuitive and similar to perl API returning true on success and undef on
>>failure, populating $!.
>
> this is close to what I would like to see.
>
> actually, I think it would be nice to be able to have a DBI-like approach:
>
> # die() on error - requires eval() logic
> PerlRaiseError On
>
> # check returns manually - no eval() required
> PerlRaiseError Off
>
> not sure how realistic it is, though...
Not quite, IMHO. DBI's user interface is tiny compared to mp2 API. I don't
think users will find it convenient. And the more guns you give them, the more
feet they will shoot.
I think croak is the way to go where it's relevant, and
success/failure/length+$! anywhere else. e.g. perl's require croaks and for a
good reason. So we should think which interfaces must croak if they fail and
which return success/failure. For example read/write interfaces should
probably be consistent with perl's read/write and return success/failure and
populate $! on failure. config interfaces should probably all croak, since if
you fail to config, it's not a momentary problem, it's a big problem in the
program design.
So from the user point of view, if they didn't check the return value of read,
they will immediately know if something went wrong, because they won't get
their data. If the config interface does croak and users don't check the
return value, it's quite possible that users won't have any idea why things go
wrong and they may even not notice that something is wrong, if the
configuration change was doing some optional thing.
If someone doesn't like their program dieing and they don't want to eval
possibly die'ing statements, wrapping their program in one big eval or one of
the exception modules will do the trick.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0 Changes
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 1. returning an error message is not perlish. it should be then
> intuitive and similar to perl API returning true on success and undef on
> failure, populating $!.
this is close to what I would like to see.
actually, I think it would be nice to be able to have a DBI-like approach:
# die() on error - requires eval() logic
PerlRaiseError On
# check returns manually - no eval() required
PerlRaiseError Off
not sure how realistic it is, though...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0 Changes
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>> #test adding config at request time
>> - my $errmsg = $r->add_config(['require valid-user']);
>> - die $errmsg if $errmsg;
>> + $r->add_config(['require valid-user']);
>
>
> I don't know about this. I was going to work up my thoughts as a result of
> another thread, but I might as well do so here...
>
> I think it's a bad practice for a persistent OO interface to die at runtime.
> what you've done means that I need to now use eval() logic to handle the
> exception, rather than simply checking the return value - several extra
> lines of code (and processing) when 1 will do just fine.
Where have you read that, Geoff? From my reading on OO it's the *OO* feature
to throw exceptions instead of returning errors.
> and it further
> obscures our interface: which methods do I need to trap with eval() and
> which can I trust not to die again?
documentation?
> I think it's ok to die at startup or something, but if your request-time
> handler dies request after request because of, say, a different
> AllowOverrides config, it's bad. I've followed this rule in my own
> persistent environments (not only mod_perl :) and found it really to be a
> best practice.
>
> so, I'd suggest re-thinking this a bit. I understand what you were trying
> to solve, but maybe there is another way? maybe call croak on
> $s->add_config but not $r->add_config?
I agree to re-think.
Here are some random thoughts of mine:
1. returning an error message is not perlish. it should be then intuitive and
similar to perl API returning true on success and undef on failure, populating $!.
2. Most users will not check the return value, and not watch the error log
(sure you can say it's their fault but we will get faulty bug reports: why
this doesn't work)
3. startup mechanisms should be consistent. If a failure to run:
PerlModule Foo
is fatal. I'd expect
$s->add_config(['PerlModule Foo'])
called from PerlRequire/PerlModule/<Perl> sections to fail just the same. Why
would you want to trap and ignore the problem I don't know. 99.9% is that you
won't want to trap that problem. For 0.01% cases I think eval is the right
thing to do.
Perhaps you're right that $r->add_config should be more forgiving. But than we
get a seemingly indentical interface add_config() behaves differently
depending on which object it's called. This is a bad as being confused to
which methods you need to trap and which not.
Moreover at the moment $r->auth_cfg() which internally calls the same
function, warns on error (but it doesn't return any error indication!) so you
have no idea whether your call has succeeded or not. what gives? this brings
us to the next item:
4. mp2's error handling mechanism is a *big* incosistent mess. So instead of
trying to figure out what to do for each method/function separately we should
come up with a some guidelines and follow them.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org