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.
yes, similar to DBI's RaiseError attribute. sounds like lots of work, though.
right. Probably not too much work if we use macros to do the job and do it right from the very beginning. Just to move from croaks to return undef/set error var we need to change lots of functions. So we better do that once. e.g. we could plant a noop macro which will croak if something and then enable it later.
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.
I don't know enough about sockets. is the 0 important? in cases like this can we return 0E0?
0 is very important, in the particular test in my patch. Using 0E0? But then we have an inconsistent API, some places we return undef other 0E0? Granted it is already inconsistent, but the idea is to fix it.
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.
yeah, that's the problem - modules will either trap their errors or not.
So perhaps that should be turned on/off from any place in
the code and not only from startup time.
yes, affecting all interpreters for a given (virtual) server.
actually only the current interpreter, you can't affect other interpreter during request 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?
right, CPAN is the bigger issue.
anyway, I dunno. something in me feels like this is probably a bad idea, or at least not worth the effort, but I'm not convinced either way. if you want to take a crack at it go for it.
It's just too big of a change to "give it a crack". I'll try to see what can be done with the socket set/get API though.
__________________________________________________________________ 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]
