Lars Gullik Bjønnes wrote: > Georg Baum <[EMAIL PROTECTED]> > writes: > > | Do you have a better idea? The regexes will never be perfect, so we must > | be able to test whether a given string denotes an existing file. > > fs::exists should never throw.... if it does we are feeding it really > bogus data already. So IMHO the try/catch should not be needed. > That is why I really would like to know _what_ throws really.
Yes, we may feed it bogus data. The problem is that we don't know whether the data is bogus or not, since it comes from regex "parsing" the LaTeX log. This is what I tried to explain above: How should we find out if this data is the name of an existing file other than using fs::exists? > | > >From what I have seen from the bug trail you have not even > | > investigated what exception that occur. > | > | No, because it does not matter IMHO: Either the string is not a valid > | filename, or it was not possible to determine whether the file exists. > | How can we tell the difference with boost::filesystem? I don't know, so > | in both cases we will not put it into the dependency list. > > But it does matter. If it is the path that throws because it is > invalid for the given platform or if it is fs::exist or > fs::is_directory is really different things. Sure, they are different, but in this context the difference is not so important IMHO. > Now they are lumped together and we do not even know which of them > that trows. > > And if it is the path... remember that we (I) did a trick when > introducing boost::fs. We setup the path name check to be "nocheck" > (in src/main.C). Perhaps that is where we should change things, either > to avoid the explict try/catch completely or to get a better/more > precise exception thrown. How could that help to avoid the try/catch block? I don't understand, it looks like a stricter check would throw more exceptions, nott less. If it is possible to test a given string whether it is a valid fs::path we could simply do that and would only call fs::exists if it is a valid path. Then we could get rid of the try/catch blocks. I don't know of such a path validity check, but maybe I overlooked it. Are you aware of such a function? Of course we could make our own (constructing a path and catching the exception), but is that really better than what we have? Georg
