How to convert one text file into one large String?
in [Java Programming]
|
Prev: How to get the file name from a String containing the path plus the file name?
Next: CodeWarrior begins on Mar 5, 06:00 pm IST. Certificates & Prizes worth 20,000 INR.
From: Patricia Shanahan on 6 Mar 2010 13:52 Tom Anderson wrote: .... > Absolutely. My code can't possibly work if the length of the file isn't > known ahead of time, so again, the right thing for it to do is blow up > with an exception. Having File.length() return -1 or throw an exception > of its own would achieve that. Returning 0 allows code written by lazy > programmers, such as exhibit A above, to fail silently, which is bad. .... Also, zero is inherently ambiguous. It fails to distinguish "The file exists, has been examined, and is definitely empty." from "Unknown length.". I think an exception would be much better. However, I am not sure it would be feasible. The Java API is, in this sort of area, at the mercy of the operating system. Patricia
From: Tom Anderson on 6 Mar 2010 17:26 On Sat, 6 Mar 2010, Patricia Shanahan wrote: > Tom Anderson wrote: > ... >> Absolutely. My code can't possibly work if the length of the file isn't >> known ahead of time, so again, the right thing for it to do is blow up with >> an exception. Having File.length() return -1 or throw an exception of its >> own would achieve that. Returning 0 allows code written by lazy >> programmers, such as exhibit A above, to fail silently, which is bad. > ... > > Also, zero is inherently ambiguous. It fails to distinguish "The file > exists, has been examined, and is definitely empty." from "Unknown > length.". I think an exception would be much better. > > However, I am not sure it would be feasible. The Java API is, in this > sort of area, at the mercy of the operating system. On unix, i assume java is calling stat(). That fills in a struct which has a field with the file mode, which includes bits indicating the kind of file - there's even a handy macro called S_ISREG which can be used to test if a mode bitfield describes a regular file. Java could easily examine that to see if the length was meaningful. I'm not a Windows expert, but it seems that while Windows does have named pipes, they live in a different namespace to normal files - they're called things like \\.\pipe\MyPipe, which would be easily recognised. I don't know if Windows has other lengthless things (other than directories) in its filesystem; i didn't see any sign of them in a quick dip into various bits of documentation. I have absolutely no idea what sort of horrors lurk in a VMS or z/OS filesystem. I believe named pipes are not among their eldritch number, though. z/OS has a unix-like filesystem which is supplied for the use of java; if that supports FIFOs and so on, it presumably makes them obvious through a correspondingly unix-like stat() call. I can't think of any other important java platforms off the top of my head. So, i reckon Java could fairly efficiently detect lengthless files on the great majority of systems it runs on, and could thus implement the fail-on-undefined-length semantics i want. tom -- Intensive Erfrischung
From: Arne Vajhøj on 6 Mar 2010 21:57 On 06-03-2010 13:52, Patricia Shanahan wrote: > Tom Anderson wrote: > ... >> Absolutely. My code can't possibly work if the length of the file >> isn't known ahead of time, so again, the right thing for it to do is >> blow up with an exception. Having File.length() return -1 or throw an >> exception of its own would achieve that. Returning 0 allows code >> written by lazy programmers, such as exhibit A above, to fail >> silently, which is bad. > ... > > Also, zero is inherently ambiguous. It fails to distinguish "The file > exists, has been examined, and is definitely empty." from "Unknown > length.". I think an exception would be much better. > > However, I am not sure it would be feasible. The Java API is, in this > sort of area, at the mercy of the operating system. But it could throw an exception if it was sure that length did not make sense and return 0 if it were not able to tell whether it was zero or N/A. Arne
From: Mike Schilling on 7 Mar 2010 02:28 Arne Vajh�j wrote: > On 06-03-2010 13:52, Patricia Shanahan wrote: >> Tom Anderson wrote: >> ... >>> Absolutely. My code can't possibly work if the length of the file >>> isn't known ahead of time, so again, the right thing for it to do is >>> blow up with an exception. Having File.length() return -1 or throw >>> an exception of its own would achieve that. Returning 0 allows code >>> written by lazy programmers, such as exhibit A above, to fail >>> silently, which is bad. >> ... >> >> Also, zero is inherently ambiguous. It fails to distinguish "The file >> exists, has been examined, and is definitely empty." from "Unknown >> length.". I think an exception would be much better. >> >> However, I am not sure it would be feasible. The Java API is, in this >> sort of area, at the mercy of the operating system. > > But it could throw an exception if it was sure that length > did not make sense and return 0 if it were not able > to tell whether it was zero or N/A. Which still makes 0 ambiguous. Anyway, given that all current Windows variants are descendents of NT, which makes them spiritual descendents of VMS, I'll bet that there are fullly supported ways to determine the type of "device" an open stream reads from, and thus whether it has a defined size. I don't know nearly enough about Linux to even speculate there.
From: Arne Vajhøj on 7 Mar 2010 09:52
On 07-03-2010 02:28, Mike Schilling wrote: > Arne Vajh�j wrote: >> On 06-03-2010 13:52, Patricia Shanahan wrote: >>> Tom Anderson wrote: >>> ... >>>> Absolutely. My code can't possibly work if the length of the file >>>> isn't known ahead of time, so again, the right thing for it to do is >>>> blow up with an exception. Having File.length() return -1 or throw >>>> an exception of its own would achieve that. Returning 0 allows code >>>> written by lazy programmers, such as exhibit A above, to fail >>>> silently, which is bad. >>> ... >>> >>> Also, zero is inherently ambiguous. It fails to distinguish "The file >>> exists, has been examined, and is definitely empty." from "Unknown >>> length.". I think an exception would be much better. >>> >>> However, I am not sure it would be feasible. The Java API is, in this >>> sort of area, at the mercy of the operating system. >> >> But it could throw an exception if it was sure that length >> did not make sense and return 0 if it were not able >> to tell whether it was zero or N/A. > > Which still makes 0 ambiguous. Sure, but it is better to have some ambiguity on 0.1% of systems than 100%. Sure portable Java requires it to work everywhere without exceptions. But when we start talking about reading from non-files on unusual operating systems, then I think that carefull coding and testing is needed anyway. > Anyway, given that all current Windows variants are descendents of NT, which > makes them spiritual descendents of VMS, I'll bet that there are fullly > supported ways to determine the type of "device" an open stream reads from, > and thus whether it has a defined size. I don't know nearly enough about > Linux to even speculate there. For anything POSIX compliant then S_ISREG(mode) should be fine. That would apply to Unix/Linux (even though not all of them are officially certified). Arne |