Subject: Re: [xsl] XPath that returns nothing From: Andrew Welch <andrew.j.welch@xxxxxxxxx> Date: Thu, 29 Sep 2011 11:14:26 +0100 |
>> So then its a case of run-to-the-end and log issues, or fail early and >> re-run individual steps. Personally I much prefer the latter, as >> theres a much faster turnaround for fixing and testing issues, but it >> does vary depending on the project. >> >> > Certainly both modes of processing (stop at first error, or find as many > errors as you can in one run) are appropriate, especially when running > tests. But I think the right approach to continuing after an error is to use > some kind of try/catch mechanism, not to suppress the error checking. Yep - the drawback with that is sometimes the later steps are affected by an error in the earlier step, so you get a load of false error reports that potentially hide genuine errors... so you end up fixing the earlier step and rerunning anyway to just get a clearer picture... and if that problem was in step 2 and step 1 takes a while, well you soon get annoyed re-running step 1 all the time :) In the fail-early scenario, you do want an error to cause that particular transform to fail and create no output, so the later transform wont happen and won't report the false errors. Provided you've got some way of reporting the number of successful transforms - ie "1024 files transformed", you know if everything has be successful or not. If 1 file has failed, you can make the fix, transform that one file, then carry on with the next step. It's been a while, but Kernow's 'directory transform' should run to the end, then list all the files that failed to transform for some reason. -- Andrew Welch http://andrewjwelch.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XPath that returns nothin, Michael Kay | Thread | Re: [xsl] XPath that returns nothin, David Carlisle |
Re: [xsl] XPath that returns nothin, Michael Kay | Date | Re: [xsl] XPath that returns nothin, David Carlisle |
Month |