and usually if there is a socket problem, you can't do much, and there is no point to eval. Most likely you will want to die.
sure. but it's the forced die that bothers me. at least if we return undef they can die with their own message or throw out something other than an automatic 500.
right, see below
Second, let's say we don't croak and return undef. We need to set a consistent variable with the error message. As you saw I've failed to convince p5p to allow us to peruse $!. And $@ is not appropriate, we have no other choce but to use some other variable. So what should it be? $Apache::err and $Apache::errstr, ala $DBI::errstr. Or should there be a separate error variables for APR and Apache, since APR eventually could be used outside mod_perl?
$Apache::err and $APR::err sound reasonable enough - most people familiar with mod_perl are familiar with DBI so it should be easy to adopt.
+1
it's a shame that we can't use $!, though, since lots of the functions have the same name as perl built-ins.
We could have a directive which could control the overall behavior: whether to croak or not (in addition to setting ::err vars). So one could turn it on to get the server pinpoint problems if they didn't code thing properly and have misterious failures. for example when you check for a blocking IO mode, you will get a false value either on failure (if we return undef) or when it returns 0. Turning that crock on failure feature on, will tell enforce croaking showing where the problem is. I like that idea. Though there is a problem with it. if a developer relies on the automatic croak without coding his own error checking a user may not have this feature turning on and then he will get misterious misbehaviors. So perhaps that should be turned on/off from any place in the code and not only from startup time. Implementation wise, it should affect everything I believe (i.e. it's either on or off), but again this may affect other people's code who did check for errors and tried to take alternative solutions if something has failed, which when this mode is enabled will not work as expected. So I'm not sure... May be we could advertise it as a debugging tool, not to be used in CPAN modules?
Also going back to my patch, what do you think about opt_set returning an old value. I've coded explicitly to get that old value before setting the new one. That sounds Perlish, but I'm not sure whether it's worth the overhead.
since you're asking, I actually prefer returning the old value on set.
Well, that's exactly what my patch does. :)
mp1 did that for lots of things, which made typical mp-type overrides (server_rec stuff, for example) able to eliminate an extra call to get()
my $old = $foo->set($val); # override $foo->set($old); # restore
And that's exactly why I coded it that way :)
__________________________________________________________________ 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]
