On Fri, 4 Apr 2003, Stas Bekman wrote:
> Nick Tonkin wrote:
> > 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?
Not important based on your answer above ...
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
