Is SmtpClient.SendAsync() really faster than SmtpClient.Send()

Question

I was refactoring some of my code into a service and I was going to roll async all the way through down to my EmailService's Send() method. I was about to replace Send() with SendAsync() and noticed the extra callback parameter. Well decided to dig in and read about it a little more in depth here:

https://learn.microsoft.com/en-us/dotnet/api/system.net.mail.smtpclient.sendasync?view=netcore-3.1#definition

I think this would be useful to set up logging to database on an error:

if (e.Error != null)
{
    Console.WriteLine("[{0}] {1}", token, e.Error.ToString());
    // TODO: Log error to DB
}

e.Cancel would never happen.

The only thing I would be concerned about is logging errors and message sent. Because the example console program says message sent even though if I have say a port wrong and the message doesn't go through. The only time it would report the error is for an ArgumentNullException or InvalidOperationException.

So logging message sent could be erroneous. But there is no way to check for sure if a message goes since it returns void and not a success bool. I guess this is better than putting the Send() in a try/catch which would be more expensive.

One alternative is to setup the callback to an empty SendCompletedCallback() and just have this:

private static void SendCompletedCallback(object sender, AsyncCompletedEventArgs e)
{
    // Do nothing
}

Then we get the benefit of Async non blocking in our emails and have the infrastructure set up for a callback if we ever need it. But we are not forced to add any funtionality at the moment.

Am I right in thinking this through here. I think I am going with this approach.

Answer 1

I found the

SendMailAsync()

method works best. You don't need a callback or a user token. Easy to implement and non-blocking.