1

I have a service that use a worker to run a periodic task.

I will not use a concrete language because it is a generic question, so I will expose the general idea.

MainProgram
{
    Worker.Start();
    wait worker;
}


Worker
{
    Execute(cancelationToken)
    {
        try
        {
             while(!CanelationToken)
             {
                 //do the task;
                 wait(1000);
             }
        }
        catch
        {
            _log("Some exception");
        }
    }
}

In the worker, I handle the exception to write in a file the problem and I don't stop the worker, I want it continues with the next iteration.

Also I would like to send an email with the error, but I am thinking where it would be the better place to send the email.

One option is in the worker, in the catch, after log the error, but perhaps it is much work than the worker should do and it would be better to handle in the main of the application, perhaps it is more a matter of the application than the core of the application.

But for that, I guess I would need to implement an event to notify from the worker to he main the exception, buecause I don't want to stop the service, I want to continue to try in the next iteration.

But this makes me to to think, if to send an email in the worker is not the best place because it is not the main responsability of the core of the worker, perhaps to log the exception it is not the best place too and perhaps it should be done in the main aplication, in the same plaec where I send the email.

So my doubt is how to struct the code, if it is better to leave the worker as light as possible or it is not a bad idea to send the email and log the exception in the worker because really it is its responsability?

Thanks.

1
  • My recommendation would be to keep it separate. You can configure Splunk (or whatever log aggregator you are using) to send the email when it sees a particular entry in the logs. Or you could log a Windows Event and there are lots of management tools for monitoring event logs and triggering alerts. This makes it easier for people using your system since they will not need to learn how your particular email system works or how to configure or troubleshoot it, and it will fit in better with any other alerts going on in your architecture.
    – John Wu
    Commented Oct 25, 2022 at 17:30

2 Answers 2

1

I recommend having an email queue somewhere -- perhaps in a database, perhaps in a file system directory. Then every time you want to send an e-mail, the contents of the mail get stored there.

Then all you need to do is to write code to actually send those emails. Maybe you can poll that directory or database table once per minute, maybe you could have some kind of notification mechanism to fire the asynchronous code to send the email right away.

The code to send e-mails periodically should be robust: it should detect when the sending was successful (so the same email won't get sent over and over again), while at the same time not marking that email as "DONE" if it wasn't really sent due to an error (in which case you try later).

You probably still want to retain each email indefinitely for future reference.

You should also have an error log somewhere, where you log all errors, because email sending can result in errors too.

Email sending can depend on network, so it's generally not possible always to send it right away. Maybe the SMTP server is down at that time.

2
  • it is good suggestion. I have the log, but the moment it is in the catch of the worker. Would you recommend to quit from this catch and handle log the exception in another place? Perhaps to have a log handler as the email handler that you suggest? Commented Oct 25, 2022 at 17:08
  • Yes, the e-mail sending should ideally be asynchronous so the code to prepare e-mail will only get information that it's queued, and the asynchronous code later handles the sending.
    – juhist
    Commented Oct 26, 2022 at 14:41
1

It sort of depends on how many tasks you expect the worker to do, and therefore how fast it needs to be. It also kind of depends on how many errors you expect.

If you expect a lot of tasks, and possibly errors, then it might be best to just fire it off to an asynchronous method which can handle it on a separate thread. If you expect very few tasks you could probably get away with just doing it in a catch if you'd rather have it all in one place.

If it was me I'd probably use an async method of some sort regardless so that I don't clutter my main code too much with error handling logic.

1
  • In my case it is just one task, to use a http client to update the dynamic IP. Commented Oct 25, 2022 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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