Why not catch general Exceptions

by

Swallowing exceptions is a dangerous practice because:

  • It can cause the user to think something succeeded when it actually failed.
  • It can put your application into states that you didn’t plan for.
  • It complicates debugging, since it’s much harder to find out where the failure happened when you’re dealing with bizarre/broken behavior instead of a stack trace.

As you can probably imagine, some of these outcomes can be extremely catastrophic, so doing this right is an important habbit.

Best Practice

First off, code defensively so that exceptions don’t occur any more than necessary. They’re computationally expensive.

Handle the expected exceptions at a granular level (for example: FileNotFoundException) when possible.

For unexpected exceptions, you can do one of two things:

  • Let them bubble up normally and cause a crash
  • Catch them and fail gracefully

Fail Gracefully?

Let’s say you’re working in ASP.Net and you don’t want to show the yellow screen of death to your users, but you also don’t want problems to be hidden from the dev team.

In our applications, we usually catch unhandled exceptions in global.asax and then do logging and send out notification emails. We also show a more friendly error page, which can be configured in web.config using the customErrors tag.

That’s our last line of defense, and if we end up getting an email we jump on it right away.

That type of pattern is not the same as just swallowing exceptions, where you have an empty Catch block that only exists to “pretend” that the exception did not occur.

Other Notes

In VS2010, there’s something called intellitrace coming that will allow you to actually email the application state back home and step through code, examine variable values at the time of the exception, and so on. That’s going to be extremely useful.

More Related Contents:

  1. Why not use exceptions as regular flow of control?
  2. Dealing with “java.lang.OutOfMemoryError: PermGen space” error
  3. When to throw an exception?
  4. Better exception for non-exhaustive patterns in case
  5. Why should I not wrap every block in “try”-“catch”?
  6. Is it really that bad to catch a general exception?
  7. Could not load file or assembly System.Net.Http.Primitives. Located assembly’s manifest definition does not match the assembly reference
  8. Design by contract using assertions or exceptions? [closed]
  9. Cause of Servlet’s ‘Response Already Committed’ [duplicate]
  10. try-catch exceptions in Swift [duplicate]
  11. When is it right for a constructor to throw an exception?
  12. simple IPython example raises exception on sys.exit()
  13. Why is exception handling bad? [closed]
  14. How do exceptions in Haskell work?
  15. How do I not log a particular type of Exception in Logback?
  16. What is causing my OLEDbException, IErrorInfo.GetDescription failed with E_FAIL(0x80004005)
  17. Why are Exceptions said to be so bad for Input Validation?
  18. Can I get detailed exception stacktrace in PowerShell?
  19. Concurrent Modification Exception : adding to an ArrayList
  20. Begin, Rescue and Ensure in Ruby?
  21. Silent failures in C#, seemingly unhandled exceptions that does not crash the program
  22. Difference between using Throwable and Exception in a try catch [duplicate]
  23. While constructing the default constructor can not handle exception : type Exception thrown by implicit super constructor
  24. What should I know about Structured Exceptions (SEH) in C++?
  25. How to serialize an Exception object in C#?
  26. ArgumentOutOfRangeException on initialized List
  27. Is it possible to catch an access violation exception in .NET?
  28. How to handle Task.Run Exception
  29. When to log a stacktrace for a caught exception
  30. Difference between a C++ exception and Structured Exception

Leave a Comment