asked on

try catch in class c#

I want to learn what is the best practice of using try catch inside of my class object. you can just assume I have simple database call and the class returns custom class like Person.

what I hope to get is when the error is occurred, a master log files will be written on it and I can have all of the log messages as I want.

ASKER CERTIFIED SOLUTION

Peter Chan

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

AndyAinscow

>>is the best practice of using try catch

Use that when there is no easier method to check if things succeeded. It is resource intensive.

eg.
if(X.PerformAction())
{
//PerformAction returns a bool indicating success
}

is better than
try
{
X.PerformAction(); //throws exception on failure
}
catch......

pepr

To add to AndyAinscow's recommendation. You should always think about exceptions as about something that is difficult to anticipate. If the method can return say boolean value, then (in theory) one bit is enough to tell you the result. If you raise exception instead, then only to form the error message with the call stack representation and all the things takes much more processor instructions. Moreover, handling the exception itself is much more complex task than passing a bool value. And if you know that you want to handle the exception explicitly anyway, then it is much easier to handle the return bool value. (The boolean value being the extreme example. The indication may be more complex, but it probably will still be less complex than the internal handling of the exception.)

ste5an

In addition to the other posts:

[..] you can just assume I have simple database call and the class returns custom class like Person.[..]

This should be a layered architecture. Thus you have a boundary, where you need to pass that information. From the database access layer, where you execute your actual code against the database, exceptions may happen, e.g. dead locks or timeouts. From the upper perspective, your business logic or UI, this kinds of errors are expectable. They can happen. Thus catching them in the database access code and transforming them to the mentioned Boolean is often a code strategy.

The other thing you need to consider: Which of the possible exceptions can you handle and keep your application in a runnable state with intact data integrity?
Here the answer is often: you can only handle common, not so unexpected exceptions. The real unexpected ones may require an internal "restart" of your application without guarantee that you can recover your application.