On Fri, 4 Apr 2003, Stas Bekman wrote:
[moving to the dev list]
Nick Tonkin wrote: [...] > Working on finishing the rewrite of porting.pod. In the above example, the > error mesage emitted is: > > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] p is not of type > APR::Pool at /home/debug/www/_perl/NPT/MyTest.pm line 9. > > This would be much improved if it said: > > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] Usage: > APR::URI->parse($pool, $uri): first argument is not of type APR::Pool at > /home/debug/www/_perl/NPT/MyTest.pm line 9.
Agreed. However this is not simple todo, because parse() is implemented as a thin wrapper mpxs_ and its args are automatically converted and the error is generated by the conversion macros. These have no clue about the usage patterns.
This is an issue with all mpxs_ wrappers which explicitly specify its arguments, rather than use ... (e.g. see mpxs_Apache__RequestRec_print in xs/Apache/RequestIO/Apache__RequestIO.h) or write a full XS wrapper (e.g. MPXS_Apache__Directive_lookup in xs/Apache/Directive/Apache__Directive.h). The first case works only for a few APIs, the second case requires a fully blown XS code.
Though I agree that the user experience is the most important thing, so eventually we might rewrite these thin wrappers to less-thin ones, with explicit conversion code and error checking, enabling usage printing. Or even better improve WrapXS to allow usage patterns which will be printed in the case of the error, in addition to the errors whatever they are.
I think this can be implemented as a new field in the map files and used in case of errors. How does it sound?
I'm not sure how that is all implemented, but it sounds like a standard error message component consisting of a usage pattern would be a Good Thing. It would be a string, right? Like "Usage: APR::URI->parse($pool, $uri)" or similar?
A string yes, but how to plug it is not trivial. Unless someone has a cool idea how to implement it, I'll the issue to the STATUS file to be resolved in the future.
It would just be important to make sure that the error message regarding usage
was only emitted when the error is actually caused by bad usage!
Certainly, just like other Usage: messages we have for selected xs subs.
(See the recent patch to TT2 improving handling of parse errors.)
Dunno what you are talking about, URL?
__________________________________________________________________ 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]
