<story><title>How can C Programs be so Reliable? (2008)</title><url>http://tratt.net/laurie/blog/entries/how_can_c_programs_be_so_reliable</url></story><parent_chain><item><author>azov</author><text>Popular C software is so reliable because of &lt;i&gt;enormous&lt;/i&gt; amount of effort spent developing, testing, and polishing it over many years - not because error handling in C is superior to that in higher-level languages.&lt;p&gt;If your python script sticks around for 30 years constantly being used by millions of people - I bet it will be rock solid as well. All other things [1] being equal [2], a program written in a higher-level language will likely be more reliable - simply because it will likely be shorter. C has many properties conductive to great longevity of software written in it, but error handling is not one of them.&lt;p&gt;Now, to the rant about not knowing the exact number of exceptions a function can throw. Most sane languages [3] give you exception hierarchy. You know that every function can throw an Exception (or Throwable, or whatever the root of all things evil is called in your language), and you either handle it or let in propagate. The important bit is &lt;i&gt;you catch exceptions based on what you can handle in a current context, not on what the functions you call can throw&lt;/i&gt; [4]. As long as you realize that every call can potentially throw, it is not important what exactly is thrown - letting you abstract away the exact nature of an error is a feature, not a bug, that&amp;#x27;s what exceptions are there for! Let&amp;#x27;s say some function deep below changed and now throws a new exception type. So what? It didn&amp;#x27;t change what you can handle, so there&amp;#x27;s no reason to modify calling function - just let the exception propagate. What if nothing in your program can handle that exception? You let it crash (hopefully to the debugger, and no, it&amp;#x27;s not ironic that I suggest it in a topic about reliable programs - crashing is a reliability feature invented to expose problems that would be hidden and hard to debug otherwise). Of course you may also put a few catch-all clauses in a very limited number of strategic places.&lt;p&gt;If you approach exceptions this way they are vastly superior to error codes.&lt;p&gt;[1] Scope of the problem, amount of effort spent on development, programmer skills&lt;p&gt;[2] Or at least on the same order of magnitude&lt;p&gt;[3] With a notable exception of C++ - I&amp;#x27;m not sure what they were smoking when they decided that throwing arbitrary values is a good idea&lt;p&gt;[4] And this, by the way, is what&amp;#x27;s wrong with checked exceptions in Java&lt;p&gt;PS. Didn&amp;#x27;t mean that having no exceptions is insane - but that if a language has exceptions, the sane thing to do is to organize them in a hierarchy with a single root.</text></item></parent_chain><comment><author>yason</author><text>I disagree with being polished. Newer C programs can be robust as well. In fact, I write C programs both for fun and at work and so do a lot of people I know, and these programs still end up being much more robust than I would even expect myself. And when you run them continuously, you will find some bugs in the program but the next bug will appear much later until you don&amp;#x27;t remember when was the last time a bug caused a failure.&lt;p&gt;There&amp;#x27;s something about the robustness you&amp;#x27;re forced to implement. I never trust scripting languages like that, not mine nor others&amp;#x27;, as much as solid C. I&amp;#x27;ve seen it way too many times that when a C program is well-written solid code, it keeps on doing what it does and doesn&amp;#x27;t give surprises. I&amp;#x27;ve had many Python scripts running for years and I always need to fix something little there every year. Maybe something has changed in some library, or I bump into a new failure mode, or something. This rarely happens with a C program once it has &amp;quot;settled&amp;quot;.</text></comment>
<story><title>How can C Programs be so Reliable? (2008)</title><url>http://tratt.net/laurie/blog/entries/how_can_c_programs_be_so_reliable</url></story><parent_chain><item><author>azov</author><text>Popular C software is so reliable because of &lt;i&gt;enormous&lt;/i&gt; amount of effort spent developing, testing, and polishing it over many years - not because error handling in C is superior to that in higher-level languages.&lt;p&gt;If your python script sticks around for 30 years constantly being used by millions of people - I bet it will be rock solid as well. All other things [1] being equal [2], a program written in a higher-level language will likely be more reliable - simply because it will likely be shorter. C has many properties conductive to great longevity of software written in it, but error handling is not one of them.&lt;p&gt;Now, to the rant about not knowing the exact number of exceptions a function can throw. Most sane languages [3] give you exception hierarchy. You know that every function can throw an Exception (or Throwable, or whatever the root of all things evil is called in your language), and you either handle it or let in propagate. The important bit is &lt;i&gt;you catch exceptions based on what you can handle in a current context, not on what the functions you call can throw&lt;/i&gt; [4]. As long as you realize that every call can potentially throw, it is not important what exactly is thrown - letting you abstract away the exact nature of an error is a feature, not a bug, that&amp;#x27;s what exceptions are there for! Let&amp;#x27;s say some function deep below changed and now throws a new exception type. So what? It didn&amp;#x27;t change what you can handle, so there&amp;#x27;s no reason to modify calling function - just let the exception propagate. What if nothing in your program can handle that exception? You let it crash (hopefully to the debugger, and no, it&amp;#x27;s not ironic that I suggest it in a topic about reliable programs - crashing is a reliability feature invented to expose problems that would be hidden and hard to debug otherwise). Of course you may also put a few catch-all clauses in a very limited number of strategic places.&lt;p&gt;If you approach exceptions this way they are vastly superior to error codes.&lt;p&gt;[1] Scope of the problem, amount of effort spent on development, programmer skills&lt;p&gt;[2] Or at least on the same order of magnitude&lt;p&gt;[3] With a notable exception of C++ - I&amp;#x27;m not sure what they were smoking when they decided that throwing arbitrary values is a good idea&lt;p&gt;[4] And this, by the way, is what&amp;#x27;s wrong with checked exceptions in Java&lt;p&gt;PS. Didn&amp;#x27;t mean that having no exceptions is insane - but that if a language has exceptions, the sane thing to do is to organize them in a hierarchy with a single root.</text></item></parent_chain><comment><author>_3u10</author><text>Yes!&lt;p&gt;Most software I&amp;#x27;ve seen can be dramatically improved by removing exception handlers. (And then fixing the underlying problems).&lt;p&gt;On the server side I prefer one exception handler which is the OS, it will kill your process, release and free all memory, file handlers, etc. Then I wrap it in a bash script &amp;#x2F; other monitoring tool, and have it immediately restart whenever it fails.&lt;p&gt;As for the server itself I&amp;#x27;ll also add an automatic reboot to the server to ensure nothing out of the ordinary persists for very long (like that PATH modification that someone forgot to add in the appropriate place to get set on restart). If it&amp;#x27;s virtualized I prefer to destroy the entire server if possible.</text></comment>