On Thu, 3 Oct 2013, Kirk, Benjamin (JSC-EG311) wrote:
> I go for (1) too,
I'm clearly outvoted by you three, but I might keep arguing if I
hadn't just been outvoted by reality too. Upon testing the proposed
libmesh_file_error() throw I discovered that even our own *examples*
can be silently bit
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?
J
Yeah - we found this out a long time ago... so we have all of our own file
exists/readable tests that we use before invoking getpot (or any other file IO).
If you were to throw an exception that we could catch that would probably be
best (then we can output our own error message for instance).
On Thu, Oct 3, 2013 at 11:10 AM, Roy Stogner 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?!
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.
In other words, make a typo in your file name or screw up permissions
on a
