3 ms·

It is a bad idea according to Microsoft. See https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1031 https://learn.microsoft.c

• scarface_74 3y ago
  This is for a library. Whatever the “root” of your code is should have a generic catch all where you do “something”, you don’t want library code (either yours or the system) to decide for the user what should be done with exceptions. As a library writer, you should do something about exceptions that you can and rethrow the ones you can’t,
  • breadwinner 3y ago
    > Whatever the “root” of your code is should have a generic catch all where you do “something” If your only goal is to avoid crashing the app then you can catch the base Exception class at the root of you code and go home. But consider the scenario that you're writing a very important method, where the functionality of your method is very important. If your method does not do its job, the rocket may crash or the patient may die. In this case you want to know what recoverable errors are possible in the functions that your method calls, correct? Wouldn't be it nice to get a guaranteed-by-compiler list of possible, recoverable, errors?
    • scarface_74 3y ago
      And then you have a list of catch blocks with the final one being the base.
      • breadwinner 3y ago
        No. You only catch exceptions you can recover from in your method. Other exceptions should be handled in higher layers.
        • scarface_74 3y ago
          I’m talking about the “root” of your app