CODEWITHSUNDEEP
c#exception
s.k.paul
s.k.paul

Reputation: 7291

Exception handling technique between class library and other projects

I'm little bit confused about handling exceptions within a hierarchy of methods.

Let's say, I've a class Logger in a class library project. Please have a look on the following code-

namespace MyLibrary
{
    public class Logger
    {
        //exposed to other project
        public static void CreateLog(String message)
        {
            try
            {
                WriteInFile(message); //calling the method below
            }
            catch (Exception Ex)
            {
                throw Ex;              
            }
        }

        //private method
        private static void WriteInFile(String message)
        {
            try
            {
                //Writing in a file
            }
            catch (Exception Ex)
            {
                throw Ex;
            }
        }
    }
}

Let's assume, I'm using that library in an ASP.NET MVC project. Code -

namespace MvcProject.Controllers
{
    public class HomeController : Controller
    {
        public ActionResult DoSomething()
        {
            try
            {
                Logger.CreateLog("some text.");
            }
            catch (Exception Ex)
            {
                 //Exception is handled here.
            }

            return View();
        }
    }
}

Hierarchy: DoSomething() -> CreateLog() -> WriteInFile()

All the three methods have try.. catch.. blocks. My questions are-

This is a fictitious example to get the problem explained.

It would be more useful for me if you post an answer with a revised code block that you suggest.

Thank you.

Upvotes: 2

Views: 6298

Answers (2)

Henrik
Henrik

Reputation: 2229

There is a very small performance hit, when wrapping code in a try,catch structure.

When a method fails to do what it was designed to do, it should throw an exception. This is "a signal" to the caller code, about where stuff went wrong.

It is up to you to catch the thrown exception. to do this, we wrap the code we want to run in a "try" statement, that sets up you code for catching an exception.

The catch block is where the code jumps to, if an exception is thrown. you can do variations of the catch statement, like "only catch a specific type of exception", or catch all exceptions.

You do not need to try/catch inside all functions. Instead we typically throw exceptions from libraries, and let the application programmer set up the try/catch structure. In this way, it is the programmer of the business logic that decides how to handle errors, not the programmer of the library..

you may sometimes want to help application programmers, by handling some errors anyway, this could be stuff like: you library catches an exception with filesystem busy before we panic, we catch the exception and retry a few times, before throwing the exception further up the stream...

It all depends on what type of exception it is.

Upvotes: 1

Jon Skeet
Jon Skeet

Reputation: 1500495

Do I actually need try.. catch in every method?

No. In fact, it's harming your diagnostics by cutting off the stack trace - you won't be able to see the original full stack trace. You could fix that by just using:

throw;

instead of

throw Ex;

... but basically the try/catch blocks are just adding cruft here. Get rid of them.

If I use that in all the methods, does it have any performance impact?

Only if an exception is thrown - but then it's potentially making it slower by recomputing the stack trace each time. I wouldn't worry about the performance though - worry about readability of code (and the effect on stack traces) first.

Upvotes: 7

Related Questions