You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/04/15 04:18:00 UTC
[mp2] error codes in the API?
So before we start polishing the API, let's agree on a few things. One of them
is the error messages variables. Since $! is unusable, we decided to use
$APR::err and $Apache::err (and errstr) (similar to what DBI does. The problem
is that it's confusing to switch between APR:: and Apache::, so it'd be nice
to have one name. So we could use /$Apache::err(str)?/, but then if APR is
used w/o mod_perl it'll be confusing. So Geoff suggested to alias these
symbols one to each other to make things interchangable. A few more ideas:
How about using /$ModPerl::err(str)?/ instead of these two. Even though it's
may be confusing when used outside mod_perl (pure APR), but better than
/$Apache::err(str)?/, IMHO.
Furthermore ModPerl is too much to type, so how about /$MP::err(str)?/? in
which case we probably want to reserve the MP namespace on CPAN?
So far we have the following 4 proposals:
1. use the right error message:
$Apache::errstr
$Apache::err
$APR::errstr
$APR::err
2. make the two interchangable via aliasing, so setting /$Apache::err(str)?/
will also set /$APR::err(str)?/
3. use just one set /$ModPerl::err(str)?/
4. use one set and shortcut it to /$MP::err(str)?/
So speak up before we started to change everything, tell which one do you like
and if you have other ideas.
Here is the patch to my recent changes to opt_(get|set) using (4):
Index: src/modules/perl/modperl_util.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.h,v
retrieving revision 1.54
diff -u -r1.54 modperl_util.h
--- src/modules/perl/modperl_util.h 8 Apr 2004 20:47:41 -0000 1.54
+++ src/modules/perl/modperl_util.h 15 Apr 2004 02:15:20 -0000
@@ -73,16 +73,22 @@
} while (0)
-/* runs a given code and if failed sets $APR::err to the error message
- * and returns &PL_sv_undef */
+/* runs a given code and if failed sets $MP::err to the rc code,
+ * $MP::errstr to the error message and returns &PL_sv_undef
+ */
#define MP_APR_RETURN_ON_FAILURE(rc_run) do { \
apr_status_t rc = (rc_run); \
if (rc != APR_SUCCESS) { \
- GV *gv = gv_fetchpv("APR::err", GV_ADDMULTI, SVt_PV); \
- sv_setpv(GvSV(gv), modperl_apr_strerror(rc)); \
+ GV *gv = gv_fetchpv("MP::err", GV_ADDMULTI, SVt_IV); \
+ GV *gvstr = gv_fetchpv("MP::errstr", GV_ADDMULTI, SVt_PV); \
+ sv_setiv(GvSV(gv), rc); \
+ sv_setpv(GvSV(gvstr), modperl_apr_strerror(rc)); \
return &PL_sv_undef; \
} \
} while (0)
+
+/* return a true value, but zero */
+#define MP_RETURN_TRUE return newSVpvn("0E0", 3)
/* check whether the response phase has been initialized already */
#define MP_CHECK_WBUCKET_INIT(func) \
Index: t/protocol/TestProtocol/echo.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/protocol/TestProtocol/echo.pm,v
retrieving revision 1.5
diff -u -r1.5 echo.pm
--- t/protocol/TestProtocol/echo.pm 8 Apr 2004 20:47:41 -0000 1.5
+++ t/protocol/TestProtocol/echo.pm 15 Apr 2004 02:15:20 -0000
@@ -19,16 +19,16 @@
# on some platforms (e.g. OSX/Solaris) httpd hands us a
# non-blocking socket
my $nonblocking = $socket->opt_get(APR::SO_NONBLOCK);
- die "failed to \$socket->opt_get: $ARP::err"
+ die "failed to \$socket->opt_get: $MP::errstr"
unless defined $nonblocking;
if ($nonblocking) {
- my $prev_value = $socket->opt_set(APR::SO_NONBLOCK => 0);
- die "failed to \$socket->opt_set: $ARP::err"
- unless defined $prev_value;
+ my $success = $socket->opt_set(APR::SO_NONBLOCK => 0);
+ die "failed to \$socket->opt_set: $MP::errstr"
+ unless defined $success;
# test that we really are in the non-blocking mode
$nonblocking = $socket->opt_get(APR::SO_NONBLOCK);
- die "failed to \$socket->opt_get: $ARP::err"
+ die "failed to \$socket->opt_get: $MP::errstr"
unless defined $nonblocking;
die "failed to set non-blocking mode" if $nonblocking;
}
Index: xs/APR/Socket/APR__Socket.h
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Socket/APR__Socket.h,v
retrieving revision 1.5
diff -u -r1.5 APR__Socket.h
--- xs/APR/Socket/APR__Socket.h 8 Apr 2004 20:47:41 -0000 1.5
+++ xs/APR/Socket/APR__Socket.h 15 Apr 2004 02:15:20 -0000
@@ -64,20 +64,18 @@
return t;
}
-static MP_INLINE SV *
-mpxs_APR__Socket_opt_get(pTHX_ apr_socket_t *socket, apr_int32_t opt)
+static MP_INLINE
+SV *mpxs_APR__Socket_opt_get(pTHX_ apr_socket_t *socket, apr_int32_t opt)
{
apr_int32_t val;
MP_APR_RETURN_ON_FAILURE(apr_socket_opt_get(socket, opt, &val));
return newSViv(val);
}
-static MP_INLINE SV *
-mpxs_APR__Socket_opt_set(pTHX_ apr_socket_t *socket, apr_int32_t opt,
+static MP_INLINE
+SV *mpxs_APR__Socket_opt_set(pTHX_ apr_socket_t *socket, apr_int32_t opt,
apr_int32_t val)
{
- apr_int32_t oldval;
- MP_APR_RETURN_ON_FAILURE(apr_socket_opt_get(socket, opt, &oldval));
MP_APR_RETURN_ON_FAILURE(apr_socket_opt_set(socket, opt, val));
- return newSViv(oldval);
+ MP_RETURN_TRUE;
}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] error codes in the API?
Posted by Stas Bekman <st...@stason.org>.
Larry Leszczynski wrote:
>>1. use the right error message:
>>
>>$Apache::errstr
>>$Apache::err
>>$APR::errstr
>>$APR::err
>
>
> I'd would have to lean toward preventing namespace pollution, so using
> ModPerl or MP doesn't feel right. Are all the error conditions truly
> generated only in APR routines? If so, I'd suggest:
> 1a. just use $APR::errstr and $APR::err
Thanks Larry,
I'm bouncing of p5p the idea of having a commonly acceptable dual-error
variable. In which case this whole issue becomes moot. So far I came up with
$E::err and Rafael suggested ${^ERROR}. I like Rafael's suggestion as it
doesn't require hijacking a namespace, but may be it's too hard to type as
it'll be used a lot. What do you think?
Feel free to voice your ideas on the p5p list.
As I mentioned on the p5p list, once we choose such a variable, there will be
no more need for things like $DBI::err, as all projects will use the same name
(if they choose to).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] error codes in the API?
Posted by Larry Leszczynski <la...@emailplus.org>.
> 1. use the right error message:
>
> $Apache::errstr
> $Apache::err
> $APR::errstr
> $APR::err
I'd would have to lean toward preventing namespace pollution, so using
ModPerl or MP doesn't feel right. Are all the error conditions truly
generated only in APR routines? If so, I'd suggest:
1a. just use $APR::errstr and $APR::err
Larry Leszczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] error codes in the API?
Posted by Stas Bekman <st...@stason.org>.
Render Web wrote:
> Stas Bekman wrote:
>
>> 3. use just one set /$ModPerl::err(str)?/
>
>
>> 4. use one set and shortcut it to /$MP::err(str)?/
>
>
> How about MP2? I do not wnat to raise the MP1/2/3
> debate again but I never saw a yay/nay decision :-)
The argument against numbers in the package names is the same, if the API is
well designed (and the underlying libs haven't changed much), most of the code
should work just the same under any perl version. .e.g. the package
Apache::Peek works identically under mp1 and mp2 and most likely will continue
to do so when mp3 comes. So does Apache::DB, Apache::Reload, etc.
>> So speak up before we started to change everything, tell which one do
>> you like and if you have other ideas.
>
>
> My reasoning for ModPerl or MP or MP2 is that it is an abstraction
> similar to DBI. In DBI the real errstr and err(no) come via the DBD.
Same here. The only catch is that once APR:: API will work outside of
mod_perl, it's going to be confusing to those developers to use a variation of
a "mod_perl" string in the error message.
That's why in the other email I've suggested a happy compromise: simply use a
totally different name, e.g. $dollar::err, and hope not to get over someone's
namespace, or simply reserve it on CPAN. I actually like that idea. Especially
if we make it a dual variable. In fact other projects (e.g., $DBI::err in 2x
series that Tim is working on) could adopt it just as the same. It shouldn't
interfere with other APIs, as long as you check the value just after the call.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] error codes in the API?
Posted by Render Web <re...@ntlworld.com>.
Stas Bekman wrote:
> 3. use just one set /$ModPerl::err(str)?/
> 4. use one set and shortcut it to /$MP::err(str)?/
How about MP2? I do not wnat to raise the MP1/2/3
debate again but I never saw a yay/nay decision :-)
> So speak up before we started to change everything, tell which one do
> you like and if you have other ideas.
My reasoning for ModPerl or MP or MP2 is that it is an abstraction
similar to DBI. In DBI the real errstr and err(no) come via the DBD.
Jacqui
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] error codes in the API?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>2. make the two interchangable via aliasing, so setting
>>/$Apache::err(str)?/ will also set /$APR::err(str)?/
>
>
> that's still my favorite if we can swing it.
I'm not sure about it. so let's say we create the alias, people get used to
use $Apache::err everywhere, so we end up with $Apache::err APR code that may
work outside mod_perl. That's like not having $APR::err at all and just making
the user confused why the two seems to work, and which one is the right one to
use.
>>3. use just one set /$ModPerl::err(str)?/
>>
>>4. use one set and shortcut it to /$MP::err(str)?/
>
>
> I don't think we can really do that with APR. once the APR interface is
> capable of being separated it makes little sense to have things in the MP::
> or any other mod_perl related namespace.
Yes, but you are doomed to have /$Apache::err(str)?/ leaked into APR code, so
IMHO it makes no difference. That's why I suggested to just use modperl in the
name. or even just some other name, e.g. ASF::err :)
>>So speak up before we started to change everything, tell which one do
>>you like and if you have other ideas.
>
>
> not really. can you explain exactly what the issue is with $!? I never
> quite understood why it wouldn't work and today I was playing with
> BerkeleyDB and saw that it relies on $! to communicate errors. I could have
> sworn that a few other modules used its dual-value nature as well, but I
> could be wrong.
We can use $! as long as we can map APR/Apache error codes to POSIX errno
codes. $! is a dual variable, which is really errno(3) in the numerical
context, and strerror(3) in the string context. Since we have error
messages/codes which aren't POSIX complient, we can't consistently use it.
I've tried to convinve p5p to extend its function to allow custom user magic,
but first, most those who cared weren't sure it was a good idea, second, we
need to support older perls which won't have it anyway.
So we end up with coming up with our own error variables. I suppose we could
even make that new variable a dual one just like $!.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] error codes in the API?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 2. make the two interchangable via aliasing, so setting
> /$Apache::err(str)?/ will also set /$APR::err(str)?/
that's still my favorite if we can swing it.
>
> 3. use just one set /$ModPerl::err(str)?/
>
> 4. use one set and shortcut it to /$MP::err(str)?/
I don't think we can really do that with APR. once the APR interface is
capable of being separated it makes little sense to have things in the MP::
or any other mod_perl related namespace.
>
> So speak up before we started to change everything, tell which one do
> you like and if you have other ideas.
not really. can you explain exactly what the issue is with $!? I never
quite understood why it wouldn't work and today I was playing with
BerkeleyDB and saw that it relies on $! to communicate errors. I could have
sworn that a few other modules used its dual-value nature as well, but I
could be wrong.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org