On Thu, Apr 05, 2001 at 10:29:03PM -0400, Sterling Hughes wrote:
> On Thu, 5 Apr 2001, Chris Adams wrote:
>
> > On 5 Apr 2001 17:05:34 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >ID: 8895
> > >The xslt_process() function *does* return false on failure.
> > > However, if the error is serious enough, the php script
> > >will exit out, as with any of the sablotron functions.
> > >Furthermore, it never sends a fatal error if the
> > >transformation fails, it sends an error of type E_ERROR for
> > >critical sablotron errors transformations and an error of
> > >type E_WARNING for warnings.
> >
> > This sounds like a question of semantics - I consider anything which will cause
> > PHP to halt execution with the message "Fatal Error" as a fatal error, even if
> > the sablotron extension is doing a RETURN_FALSE internally. Since there's no
> > possible way for a PHP developer to trap such an error, it sounds like the
> > documentation should be updated to reflect the way xslt_process() actually
> > behaves.
> >
>
> In some cases you *can* trap the error, that's why its documented as so.
> Other cases its not possible (E_WARNING or no error thrown, such as
> inability to allocate memory), its the same way with many other functions
> in php.
True - I just think this should be reflected more in the documentation (even if
it is just "really nasty errors can't be trapped"), particularly in the case of
functions like this which could die on user-provided data. Similarly, I'm
guessing that Sablotron doesn't provide more debugging information but is there
any way it could be a little more informative? It's a little frustrating to get
that sort of error with 30K of complex XSL.
Chris
PGP signature
