You've defined that function with an attribute saying not to ignore the returned value. Is it right to explicitly silence an explicit warning?

▲

amluto a day ago | parent | next [-]

I want some defined way to tell the compiler that I am intentionally ignoring the result.

I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?

▲

dotancohen 18 hours ago | parent [-]

Yes.

When my database logging fails, I write a file that logs the database fail (but not the original log file).

When my file logging fails, depending on application, I'll try another way of getting the information (the fact that for file logging failed) out - be that an http request or an email or something else.

Databases fail, file systems fill up. Logging logging failures is extremely important.

▲

amluto 18 hours ago | parent [-]

And when that last way fails, what do you do?

I like to have a separate monitoring process that monitors my process and a separate machine in a different datacenter monitoring that. But at the end of the day, the first process is still going to do try to log, detect that it failed, try the final backup log and then signal to its monitor that it’s in a bad state. It won’t make any decisions that depend on whether the final backup logging succeeds or fails.

	▲	dotancohen 16 hours ago \| parent [-]
		I'm not working on anything life-critical, one additional layer of redundancy is all I budget for. If both my database is down and my local filesystem is full simultaneously, things have gone bad and I've likely got lots of other symptoms I'm going to find to direct me.

▲

MathMonkeyMan a day ago | parent | prev [-]

Sometimes. For example, you might be setting a non-crucial option on a socket, and if it fails you don't even care to log the fact (maybe the logging would be too expensive), so you just ignore the return value of whatever library is wrapping setsockopt.