#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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
