I expect that exception handling is usually supported by a C++ program. I wonder why your function "NinjaMain" does not contain corresponding try and catch instructions so far.
How do you think about recommendations by Matthew Wilson in an article?
Would you like to adjust the implementation if you consider effects for uncaught/unhandled exceptions like they are described by Bruce Eckel?
Ninja uses no code that can throw exceptions. In fact, it even disables exception support (-fno-exceptions) for code size reasons.
I find the mentioned configuration parameter an update candidate. Do you prefer the error handling strategy "crash-only software"?
Do C++ exceptions provide the potential for improved error handling?
I do not want try/catch "everywhere". - I imagine that the software can eventually benefit from caught C++ exceptions if recoverable error situations happen which can also be handled with retries.
tfarina, please don't speak as if you are responsible for the decisions made in Ninja. It is entirely separate from Chrome and the decisions are mine.
elfring, thanks a lot for your bug reports. Your attention to detail is very welcome and I think the ideas mentioned in the other bugs are good. I will be slow to respond as I am on vacation with slow/no internet.
To answer this question briefly, yes, the idea of crash-only software has been very influential on how I think about software (in some sense my reluctance to add a daemon mode to Ninja is due to that -- there's only one code path for loading state and it is frequently tested and fast). There are also many places memory is allocated without a matching delete for similar reasons.
However, all of the code was written with exceptions disabled (many functions use an extra string* out param for passing error state around). I'm not experienced writing exception-safe C++ code so I expect there are many places that would need careful review to introduce exceptions at this point. And as you already observed, we need to be diligent about checking return codes from libc functions regardless (we recently had a bug when you run out disk space, an fprint would fail in an uncaught manner). So I would prefer to not use exceptions at all.
If you have recommendations as how to better handle the termination behavior for fatal errors within STL I welcome your advice. I haven't read the articles you linked yet because I am about to get in a hot tub. :)
Would you like to reconsider the compilation parameter selection eventually?
Do other users try out different ones for their applications?
You can choose an error handling strategy. When do you prefer not to call "abort" for specific "exceptional situations"?
I think there's nothing to do here -- Ninja disables exceptions at compile time and none of the code is exception safe, so it'd be a bad idea to turn them on now. I'm ok with crashing on any error in C++ code (e.g. STL) we invoke that uses exceptions.