RE: File utilities on exproc.org

+1 for changing the output ports. I'm pretty sure I have mentioned before
on occasion that things like logging, and file i/o integrate best if they
effectively do an identity transform, and just have logging and file i/o
as side effect.

+1 for just throwing error in case of failure

In case you want to ignore the failure, I would expect the output either
to still be identity of the input (as far as that makes sense), or simply
empty. If I wanted to do something with c:error, I would want to jump to
somewhere else (with try-catch), and take properly care of that there in a
general way, not inline at each step that could fail..

Cheers,
Geert

> -----Oorspronkelijk bericht-----
> Van: fgeorges@gmail.com [mailto:fgeorges@gmail.com] Namens Florent
> Georges
> Verzonden: maandag 25 maart 2013 0:52
> Aan: QuiXProc XProc
> CC: Imsieke, Gerrit, le-tex; XProc Dev
> Onderwerp: Re: File utilities on exproc.org
>
>   Which is syntactic sugar for try/catch.  I'm not saying syntactic
> sugar is not something XProc needs, but then it would probably bets
> addressed at the level of XProc itself (could be a standard attribute)
> rather than each step inventing its own vocabulary for that.
>
>   Just my 2 cents...  Regards,
>
> --
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
>
>
> On 24 March 2013 23:30, QuiXProc XProc wrote:
> > Probably then the attribut should be "ignore-on-error" and the value
> being
> > the QName of the error (or a list of QNames ?), instead of
"error-if-fail"
> >
> > Mohamed
> >
> >
> > On Sun, Mar 24, 2013 at 7:57 PM, Florent Georges wrote:
> >>
> >> On 24 March 2013 19:37, Imsieke, Gerrit, le-tex wrote:
> >>
> >> > A use case: I want to make sure that a directory is empty
> >> > before I extract a zip to it (creating the directory if
> >> > necessary).  So I'm deleting the directory before extraction,
> >> > and I don't want to be bothered by an error if the directory
> >> > doesn't exist.  Try/catching this would feel too verbose,
> >> > although I admit that other errors, such as insufficient
> >> > privilieges, could be cought.
> >>
> >>   I think that's precisely my point.  If you want to ignore a
> >> precise error, because you know that it makes sense in your case
> >> to ignore THAT error, then catch that error.  If something else
> >> happens, it will resolve to a proper error as it should do.
> >>
> >>   If you ask to ignore the error and get a c:error instead then
> >> you have to use conditional structures, which are even more
> >> verbose... (is it a c:error document?, is it an error document
> >> for an expected error?, etc.)
> >>
> >>   But it is true that I usually pay more attention than others to
> >> having proper error detection and handling.  So it might just be
> >> me.
> >>
> >>   Regards,
> >>
> >> --
> >> Florent Georges
> >> http://fgeorges.org/
> >> http://h2oconsulting.be/
> >>
> >

Received on Tuesday, 26 March 2013 06:50:14 UTC