Question Best practice for Exception Handling

[Cobalt]

Hello all,

I was hoping for some advice or suggested reading for Exception Handling, specifically how errors should 'bubble up' from their source to root of the application.

At the moment I'm working on a windows service which carries out a check, then an action, before sleeping for a time then starting over. The checks and actions being done require a Database queries (to multiple types of databases) and local File access. There is also need to email and log errors in some way.

I have the main Service class, and I've then created a number of other classes to encapsulate the code for all the various Database access, File access, logging and emailing.

During the run through the main Service class all the other classes are instantiated and disposed of when required.

My query is this: If any of the sub classes have issues that would cause an exception (database being offline, invalid file paths or permissions etc) I capture the error inside the class, log it and email it out. How is it best to register this within the ongoing flow of the main Service logic so that it does not try and continue when key data might be missing?
Should I not catch the error in the sub classes and just wrap a giant Try Catch around the main Service? (seems a very bad way of doing things :smash

Thanks

 

[Cobalt]

Hi everyone,

I'd hoped I'd explained myself OK, and the query seems a reasonable one; does anyone have a view?

Thanks

 

[JuggaloBrotha]

Exception Handling Best Practices in .NET - CodeProject

Just use Try/Catch blocks around unsure code (like the database calls)

 

[jmcilhinney]

Ideally, your application should have a separate service (business logic) layer and data access layer. Quite possibly you would have no specific exception handling in your DAL and any exceptions thrown would bubble up to the service layer. You might also have low-level exception handling in the DAL and then create your own higher-level exceptions to throw up the call stack. The service layer would then decide what to do and probably return a failure result to the application layer.