Return to Answer

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information).

But often this top-level exception handler would not be implemented as an actual try..catch block, but rather would be handled by the application framework. E.g. in a typical web framework you wouldn't need to write try...catch around every request handler or page generator, but rather you would register the generic exception handling code in a single place. If you use ASP.NET MVC you can use OnException or similar and save a lot of boilerplate exception handling.

Another (less common) situation is if you have a unreliable library which provides a non-essential service. Say you have an application with a plug-in architecture where third-parties can provide modules which will be loaded dynamically. It would make sense to catch all exceptions when calling into these plug-ins, since you dont want a faulty plug-in to take the whole application down.

Even internal modules could be treated as unreliable. For example, I have heard rumors that Microsoft treats subsystems in Office like this. If the grammar checker module throws an unexpected exception, it is better to show a dialog with "unexpected error in grammar checker" and continue without the check, rather than having the whole application terminate.

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information).

But often this top-level exception handler would not be implemented as an actual try..catch block, but would be handled by the application framework. In a typical web framework you wouldn't need to write try...catch around every request handler or page generator, but rather you would register the generic exception handling code in a single place. If you use ASP.NET MVC you can use OnException or similar and save a lot of boilerplate exception handling.

The important thing is that the application or request is still terminated. What is discouraged is catching exceptions indiscriminately and then continuing the execution as if nothing happened. Since an unexpected exception would mean the application state is compromised in some unknown way, continuing execution will just lead to further errors and data corruptions down the line, which can be incredibly hard to debug.

Another (less common) situation where it makes sense to catch everything: If you have a unreliable library which provides a non-essential service. Say you have an application with a plug-in architecture where third-parties can provide modules which will be loaded dynamically. It would make sense to catch all exceptions when calling into these plug-ins, since you dont want a faulty plug-in to take the whole application down.

Even internal modules could be treated as unreliable. For example, I have heard rumors that Microsoft treats subsystems in Office like this. If the grammar checker module throws an unexpected exception, it is better to show a dialog with "unexpected error in grammar checker" and continue without the check, rather than having the whole application terminate.

Note that this only works if the module can be clearly isolated from the main application, so you can be sure the error inside the module does not corrupt the state of the program at large. For example you would need to disable the plugin or module after the first unexpected exception, since it has a corrupted state. So this is only possible if the application has been explicitly designed to allow this level of isolation of the modules in question.

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information).

But often this top-level exception handler would not be implemented as an actual try..catch block, but rather would be handled by the application framework. E.g. in a typical web framework you wouldn't need to write try...catch around every request handler or page generator, but rather you would register the generic exception handling code in a single place.

Another (less common) situation is if you have a unreliable library which provides a non-essential service. Say you have an application with a plug-in architecture where third-parties can provide modules which will be loaded dynamically. It would make sense to catch all exceptions when calling into these plug-ins, since you dont want a faulty plug-in to take the whole application down.

Even internal modules could be treated as unreliable. For example, I have heard rumors that Microsoft treats subsystems in Office like this. If the grammar checker module throws an unexpected exception, it is better to show a dialog with "unexpected error in grammar checker" and continue without the check, rather than having the whole application terminate.

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information).

But often this top-level exception handler would not be implemented as an actual try..catch block, but rather would be handled by the application framework. E.g. in a typical web framework you wouldn't need to write try...catch around every request handler or page generator, but rather you would register the generic exception handling code in a single place. If you use ASP.NET MVC you can use OnException or similar and save a lot of boilerplate exception handling.

Another (less common) situation is if you have a unreliable library which provides a non-essential service. Say you have an application with a plug-in architecture where third-parties can provide modules which will be loaded dynamically. It would make sense to catch all exceptions when calling into these plug-ins, since you dont want a faulty plug-in to take the whole application down.

Even internal modules could be treated as unreliable. For example, I have heard rumors that Microsoft treats subsystems in Office like this. If the grammar checker module throws an unexpected exception, it is better to show a dialog with "unexpected error in grammar checker" and continue without the check, rather than having the whole application terminate.

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information).

But often this top-level exception handler would not be implemented as an actual try..catch block, but rather would be handled by the application framework. E.g. in a typical web framework you wouldn't need to write try...catch around every request handler or page generator, but rather you would register the generic exception handling code in a single place.

Another (less common) situation is if you have a unreliable library which provides a non-essential service. Say you have an application with a plug-in architecture where third-parties can provide modules which will be loaded dynamically. It would make sense to catch all exceptions when calling into these plug-ins, since you dont want a faulty plug-in to take the whole application down.

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information).

But often this top-level exception handler would not be implemented as an actual try..catch block, but rather would be handled by the application framework. E.g. in a typical web framework you wouldn't need to write try...catch around every request handler or page generator, but rather you would register the generic exception handling code in a single place.

Another (less common) situation is if you have a unreliable library which provides a non-essential service. Say you have an application with a plug-in architecture where third-parties can provide modules which will be loaded dynamically. It would make sense to catch all exceptions when calling into these plug-ins, since you dont want a faulty plug-in to take the whole application down.

Even internal modules could be treated as unreliable. For example, I have heard rumors that Microsoft treats subsystems in Office like this. If the grammar checker module throws an unexpected exception, it is better to show a dialog with "unexpected error in grammar checker" and continue without the check, rather than having the whole application terminate.