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:[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]
