From: John P. <jwp...@gm...> - 2013-10-03 18:34:29
|
On Thu, Oct 3, 2013 at 11:10 AM, Roy Stogner <roy...@ic...>wrote: > > The current GetPot behavior (discovered the hard way) when asked to > parse an unreadable config file is to behave as if you'd asked it to > parse an empty file instead, and leave no indication that a file open > error occurred. > Really?! That's pretty annoying... In other words, make a typo in your file name or screw up permissions > on a shared file and you're going to be stuck diagnosing a bunch of > weird, seemingly unrelated errors much later in your code. > > The best workaround to detect unreadable files is to then try > reopening the file with an ifstream in user code, but that's slightly > ugly and it's technically subject to a race condition. > > A few possible fixes we could put in: > > 1. Throw an error when a file can't be opened. > > 2. Set a flag (equivalent to the stuff in std::ios) that can be tested > after parsing. > > 3. Add a GetPot method for parsing any isteam - then the user can make > sure an ifstream is valid themselves. > > My first impulse would have been (1), but it breaks backward > compatibility for anyone depending on the "don't need an empty file to > use configuration defaults" behavior, and it's not consistent with the > way std::ifstream behaves. I'm thinking of adding both (2) and (3). > Anyone else have preferences or other ideas? > My first impulse would be (1) as well. I don't mind breaking the backwards capability of people intentionally specifying an unreadable filename to open :-P My issue with the iostream approach is that I never remember to religiously check the failbit/badbit stuff, or exactly _how _to do it in case I do remember. I imagine the standard library is a bit more constrained than we are in when they can/cannot throw an exception... -- John |