I have read that we should only catch exceptions that can be handled, which makes catching the base exception class (C# in this case) a bad idea (on top of other reasons). I am currently part of a project in which I so far have yet to see anything but the base exception being caught. I mentioned that it is considered bad practice to do so, but the response was "This service needs to run 24/7, so that is the way it is.".
Since I did not have a good response for how to properly handle exceptions in a program that needs to run 24/7, I am now here. I have not managed to find any information / suggestions on how to deal with exception handling in "critical" programs / services that needs to run around the clock (and in this case I believe it may be ok if the service is down for a minute or two, so not even critical). I understand it depends on the exact nature of the program. The requirements for a program that can cause life threatening issues are quite different compared to a log scanner for an online game.
Two examples:
1: A type-ahead service for customers of the Brittish railways, used when they searching online for railway stations.
2: A program that automatically controls the railway switches for the above railways based on realtime information provided from various sensors in the tracks, trains etc.
The first program would probably not cause a major issue if it went down for a minute or two, wheras the latter could cause human casualties. Suggestions on how to deal with each? Pointer to where I can find more information and thoughts on this issue?
catch Exception
. That doesn't mean your program works, it means that failures let application state get corrupted while it continues to execute, a vastly more dangerous place to be. A crashed program might be disastrous, but a program that's in an invalid state but still performing actions can be actively disastrous.