Home/ Questions/Q 266347
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T22:50:51+00:00

(Long time reader of SO, first time asking a q. I’m quite new to

  • 0

(Long time reader of SO, first time asking a q.

I’m quite new to C# having been in the PHP/Ruby/Python world for many years so I apologise if this is a dopey question.)

I’m doing some maintenance on an old C# app that is crashing whenever SmtpClient.Send() fails. From the little I’ve gleaned from the MSDN, I can see the obvious way to fix this, but my question is also concerned with the more general case.

As per the MSDN:

  try {
          client.Send(message);
  }  
  catch (Exception ex) {
          Console.WriteLine("Exception caught in CreateTestMessage2(): {0}", 
                ex.ToString() );
  }

This all makes sense to me, but I’ve also always thought that whenever you can prevent the possibility of the error you do so. Is there anything you can (and should?) do here to reduce the possibility of the Send() throwing exceptions?

I’m assuming there are situations where it’s impossible to prevent the possibility of an exception, so you have to handle it, but are there any general style guide or rules that people use to guide them?

Again, sorry if this is a crap question. I tried searching SO and Google as much as I could.

EDIT: I just found this question Best practices for exception management in java or C
which may well go someway to answering my question.

EDIT2: Thanks for the prompt feedback, incredibly fast. I’ve been thinking about the problem a bit more and perhaps this could further refine what I’m asking.

Is it correct to say that certain exceptions, like SmtpException, really can’t be avoided? Is it even more correct to say that it is the correct style to use exceptions like SmtpException to tell you that something went wrong with the send and you just handle it however you’d like?

I feel like I’m sounding a bit dim in this question, but I’m asking because anything I can learn is good for my confidence.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    When catching exceptions, be as specific as possible if you know what kinds of exceptions to expect from the invoked method. This will allow, for example, errors such as OutOfMemoryException to continue to bubble up the stack where it should go unhandled and then your app will fail fast (which is probably a good thing because your system is now in an unknown state and you should not carry on).

    There are different schools of thought on this, however; in some instances (say you’re an NT service) you want high availability of your app, and crashing in production because you get NullPointerException on some unforeseen code path may not be desirable as long as that exception gets logged and you have the ability to then issue a QFE (not to mention revise your test regime). If you’re a console or forms app, then recovery is a different story since the exception could be surfaced to the user and they can interactively decide what the appropriate action is.

    My general advice: catch specific exceptions as close to the source as possible, let the rest bubble up the stack and have it logged at a point where you have enough context to later on try and repro the exception. Be wary that catching then re-throwing is expensive; a scenario in your example where you might want to do this would be if, say, the SmtpException was a connection timeout (I’m making this up), then one strategy might be exponential back off and retry up to n times since the mail server might be down, then finally give up and rethrow if you don’t succeed.

    The really short answer is: It All Depends.

    • 0