Add API to silence libMesh::err

[lindsayad]

In a few places in MOOSE I have try-catch behavior that essentially tries to perform a second order boundary value calculation that may result in a singularity if there are multiple non-orthogonal boundary faces, and if so then it falls back on a first order calculation. The singularity comes through in the LU decomposition of of a dense matrix. I'd like to hide this from the user which means silencing the cerr that comes out of the decomposition routine.

[roystgnr]

Something like:

libMesh::err.flush(); auto old_buf = libMesh::err.rdbuf (nullptr); do_my_stuff(); libMesh::err.rdbuf (old_buf);

I guess? Assuming you've got a catch(...); otherwise you'll want some kind of RTTI to make sure old_buf gets restored even if something weird gets thrown.

[roystgnr]

You ought to be able to do the same (independently; this was one reason for making a libMesh::err distinguished from std::cerr) to cerr if there's a lower-level C++ library putting its output there. If there's a lower-level C library using stderr ... looks like freopen() might be what you want, but I've never used that.

[lindsayad]

libMesh::err.flush(); auto old_buf = libMesh::err.rdbuf (nullptr); do_my_stuff(); libMesh::err.rdbuf (old_buf);

I remember seeing something like that in my stack overflow searches. The current solution I'm using in MOOSE is the second answer to https://stackoverflow.com/questions/19069058/is-there-a-way-to-switch-on-off-stdcerr-or-equivalent

[roystgnr]

Setting failbit? That scares me. I don't recall ever testing (or thinking I'd want to test) cerr specifically, but testing whether a stream is currently valid or not gets done to other streams at least, and there's a semantic difference between "this is valid, don't worry your head about where the data goes" vs "this is invalid". The latter isn't just less clear, it's almost an invitation to freak out and throw an error.

[lindsayad]

You don't like living on the edge of danger? 😆

[lindsayad]

Darn, thread failures on https://github.com/idaholab/moose/pull/22130 made me realize that the rdbuf method is not robust if there are multiple threads hitting the code path ... what can often happen is that the final rdbuf ends up being nullptr!