- From: Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>
- Date: Sun, 24 Mar 2013 19:37:48 +0100
- To: xproc-dev@w3.org
On 24.03.2013 17:40, Florent Georges wrote: > By the way, I am not convinced by the 'error-if-fail' which if false > returns the c:error in case of error. That is really like catching > the error and returning its c:error document, the only difference > being it saves the user typing the try/catch structure. I am not sure > that is really helping the user at the end of the day. Forcing > try/catch promotes another way of handling errors, rather than > ignoring them silently (which will occur I guess with > error-if-fail="false"). I think it’d be too paternalistic to insist on try/catch here. 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. On the other hand, if delete fails because of lacking privileges, the subsequent zip extraction will fail, too, with a proper error. Given the degree of verbosity that XProc sometimes demands, I actually like that I’m able to avoid complex constructs with a single attribute (and probably with attribute value templates in V.next). Just my € 0.02. Gerrit
Received on Sunday, 24 March 2013 18:38:21 UTC