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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--