IMHO if that is ok depends mostly on the context of the Do
method, and what you know about the stuff in the try
-block. Lets assume you have an UI application, and the Do
part is just a Button-Click handler. Lets further assume the part within the try
block does some fairly complex non-UI things which might fail with any kind of unforseeable exception (but normally it should not, and when it does, there has happened something severe). So if your failure handling strategy is to display the exception message to the user and let him or her decide what to do next (for example, he can decide to close and restart the application, or to ignore the error), then catching all type of exceptions is just the way to go. That might not be a perfect solution, but it is pragmatic and works for a lot of real world cases.
Of course, you should make sure the user has enough information to make the correct decision. A general message like "an Exception occurred" is typically not enough information. So think about what you can present to your users and what not. If you fear your typical user cannot understand the failure message, show him the "general message", but make sure the support people or admin can get the real message afterwards (maybe from a log file, maybe from a separate menu entry etc.) If you use something like a log file, logging the stack trace of the exception maybe also a good idea, since it will help you (the developer) to find the root cause in case of an internal program error.
However, if you know that the part within the try
block can sometimes throw an exception which makes it impossible for your program to proceed (like an OutOfMemoryException
, or maybe an exception which indicates that a severe internal program error has occurred, or something like that), you should catch that individually, show the reason of failure to the user and end the program afterwards automatically. Think about what the most user-friendly behaviour is. Does it make sense to let the user decide if the program should proceed, or is there a chance if the user ignores the error, that he will loose or destroy parts of his data now? If the latter is the case, better not let the user decide - better end the program in a controlled manner.
The former was just an example - the gist is: think about the responsibilities for failure handling: what is in your case the responsibility of the user, what is the responsibility of the UI part (the button handler), and what is the responsibility of the part in the try
block - then you can make a decision of which exceptions to catch and which information to display.