-2

If I'm writing a method, in C# for example, I will use a try catch block.

Let's say the method adds some numbers but I log exceptions in the catch block. What's the best way to handle an exception causes in the catch block? e.g. the method may have an unrelated exception to the logging in the catch block throwing file not found (maybe file was deleted between file existence check and writing to it).

What's the best way to handle this and what's the general behaviour in C#?

closed as too broad by Robert Harvey May 12 at 3:16

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Before we look at exceptions which the logger may throw, let's look at exceptions which your method may encounter. If you catch exceptions inside the method, can you do anything about them (aside from logging)? Do you need to do anything to recover from those exceptions (or are they non-threatening)? Can you recover from those exceptions at all? One of the rules for exception handling: Only catch exception when you can do anything about it. (There was a good discussion about exception earlier today, coincidentally.) – Nick Alexeev May 9 at 23:14
  • 2
    "If I'm writing a method, in C# for example, I will use a try catch block" That's your first mistake, right there. A try catch block should not be the default; it should be the exception. – David Arno May 10 at 9:19
  • What would be some examples of being able to recover from an exception with something other than logging? And presumably this goes in the caller's catch block (logically). – GurdeepS May 10 at 22:15
  • The problem with all the answers here is it boils down to "I'm writing an application, what should it do?" ... "It depends". I think it's too late to be more specific, so it's a downvote from me, sorry. – Nathan Cooper May 11 at 16:11
2

Do not fail quietly. Logging the exception aids debugging. If the log fails you need another way to make noise. Popping up a dialog box is one way. Sending text to std:err is another. Flashing a red light and ringing a klaxon is another. Heck you can access the system bell and use beep codes. Just get some humans attention so they do something about the rat that gnawed through your data cable.

As for recovering that's a different issue. You recover only when you can put the system back into a safe stable state. If you can't predict what will happen next, can't guarantee that data will be safe, that system is secure, that the system isn't about to send the president threatening emails, then the responsible thing to do is roll over and die. Sometimes crashing is what you should do. It's why systems crash rather than quietly tear themselves apart.

0

Carefully reconsider what you're doing in that catch block.

You certainly don't want to catch and ignore exceptions. As you've noticed, logging them in your low level code introduces the possibility of another exception occurring in the catch block. But the bigger issue is that logging exceptions in your low level code introduces a dependency on whatever logging framework or log file you're using, which makes your code less reusable. So consider not catching the exception there. Let it propagate so the caller can decide how to handle and report it.

  • Thanks that makes sense. So when catching exceptions from say an API I would handle the exceptions in the business logic (argument exceptions, etc, and logging files being deleted, etc). – GurdeepS May 10 at 22:13
0

If you know of possible reasons for your code to fail (null values, file not found, error from a service), then you need to take those situations into account in your code. Check for nulls, empty objects or missing files, DO NOT use a try-catch block as a mechanism to handle failure paths in your algorithms.

Also, log as much as you can of the exception, don't try to differentiate between them. And, don't use try-catch blocks in all your methods. Usually, you'll have a process start point (from which your main starting method is called), and that is where you'll want to put it. Otherwise, you'll risk hiding exceptions or your system not letting you know it has failed.

-1

You should just handle them in usual way - by nesting one more try-catch into catch block. Of course you'd better encapsulate your logger into a separate function. C# as well as most modern compiled typed languages (Java, C++, C and many others) will handle nested, try-catch with no problems (both - inside catch or inside try). And I don't mension other languages not because they won't, but because I don't know them all. JavaScript also has no problems with this.

Not the answer you're looking for? Browse other questions tagged or ask your own question.