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?
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! (See the recent
patch to TT2 improving handling of parse errors.)
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
