Catch exceptions in main()?

[elfring]

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?

[nico]

Ninja uses no code that can throw exceptions. In fact, it even disables exception support (-fno-exceptions) for code size reasons.

[elfring]

I find the mentioned configuration parameter an update candidate. Do you prefer the error handling strategy "crash-only software"?

[tfarina]

On Mon, Feb 25, 2013 at 6:15 PM, Markus Elfring notifications@github.comwrote:

I find the mentioned configuration parameterhttps://github.com/martine/ninja/blob/d3c4cf1b36b132a2fc6f79970b32046ac4eaeef9/configure.py#L139an update candidate.

What you mean by this?

Do you prefer the error handling strategy "crash-only softwarehttp://en.wikipedia.org/wiki/Crash-only_software "?

I think ninja follows what we do in Chrome, i.e, no exceptions!

Why you want us to enable exceptions?

Thiago

[elfring]

Do C++ exceptions provide the potential for improved error handling?

[tfarina]

On Mon, Feb 25, 2013 at 6:43 PM, Markus Elfring notifications@github.comwrote:

Do C++ exceptions provide the potential for improved error handling?

It's still not clear what you are proposing here. Please, make it clear.

You want us to use try/catch everywhere? If yes, why? What does it improve? Why is it better than Fatal?

Thiago

[elfring]

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.

[evmar]

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. :)

[qhuo]

Is it true that ninja does not use exception? I think this is quite hard if one uses new, and STL containers like vector and string. Actually, I don't even know how std::vector::push_back would do if there is no more memory.

On Mon, Feb 25, 2013 at 10:06 PM, Markus Elfring notifications@github.comwrote:

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.

— Reply to this email directly or view it on GitHubhttps://github.com/martine/ninja/issues/508#issuecomment-14079025.

[elfring]

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"?

[evmar]

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.