Re: [Libmesh-devel] Modifying GetPot to warn about unreadable files

[Kirk, B. (JSC-EG311) <ben...@na...>]

I go for (1) too, but maybe it could be defeated if an environment variable (libmesh_no_getpot_err?) is set?  If someone is unwittingly relying on this and they are using someone else's libmesh installation they could then set the variable and go about their business until they fix the issue?

Just a thought.




On Oct 3, 2013, at 1:34 PM, "John Peterson" <jwp...@gm...<mailto:jwp...@gm...>> wrote:




On Thu, Oct 3, 2013 at 11:10 AM, Roy Stogner <roy...@ic...<mailto: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
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Lib...@li...<mailto:Lib...@li...>
https://lists.sourceforge.net/lists/listinfo/libmesh-devel