> 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. > 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? > 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. > 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. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
