CODEWITHSUNDEEP
c#exception
GurdeepS
GurdeepS

Reputation: 67283

Difference between catch block and throw new Exception in method

In a method, I want to be able to insert a value into a div which is part of the html document I choose to parse.

public void AddToDiv(string div)
{
    //Code to read the html document and look for the div 
    //(name specified as the parameter of this method).
}

Question is, I could specify a div called "abc" but the html document may not have this div. Fair enough, but what is the difference between me saying:

try
{
    //Method logic to parse document for the div
}
catch(ArgumentException ex)
{
    // (I wouldn't supress this catch block in production code, 
    // just omitting body details for simplicity.
}

OR

public void ParseDocument
{
    //Logic here...

    if(!document.Contains(div)
    {
    throw new ArgumentException();
    }
}

In short, what is the difference between a catch block and saying throw new [ExceptionType here] in the main logic block? How do I decide which is to use?

Thanks

Upvotes: 2

Views: 3358

Answers (5)

Pianosaurus
Pianosaurus

Reputation: 5768

The question is: If ParseDocument(...) cannot do what you want it do do, should it fail silently? If so, use a try{} catch{} inside it. If you need the calling code to know that ParseDocument failed, it should throw an exception that this calling code can catch.

Upvotes: 0

chriscena
chriscena

Reputation: 478

There is a third option, but I'll write more about it later.

First of all, catching exception is all about catching errors you don't expect, handling them and either continue or close down gracefully.

Throwing exceptions should be used when you encounter situation which shouldn't occur or should be handled elsewhere. If you want to handle this error outside your method, this might be your solution.

The third alternative is to actually avoid errors you know may occur. You could for example check if the div exists and not do anything if it doesn't, also known as defensive programming.

Upvotes: 1

Binary Worrier
Binary Worrier

Reputation: 51739

Personally, I'd check for existence, rather than allowing the exception to be thrown, it's easier to determine the flow of logic, and fits better with the intent of your code.

See these questions and answers for a broader discussion

When to throw an exception

Is there any valid reason to ever ignore a caught exception

How slow are .net exceptions?

EDIT:

On second thoughts, you should consider the expense of the "containts" check. If it's likely to be as expensive as actually getting the div, and it's doubling the time it takes the routine to run and if this lag degrades performance to the point where it'll be noticed, then possibly it's better to just go and get the div. I'd still catch it and throw the ArgumentException, with the original exception as the inner exception.

NB: Don't optimise unless you need to.

Upvotes: 2

Victor
Victor

Reputation: 4721

well the Try/Catch is more expensive, and it should be used to handle unexpected errors. In this case you know you will possibly get an error and dont have to "try"

Upvotes: 0

Jimmy
Jimmy

Reputation: 91502

throwing and catching are two opposite sides of exception handling. The component that encounters a disaster and can't recover from it throws the Exception. Somewhere lower down on the stack, a calling component can catch the Exception and handle it.

The difference is in this case, the pattern would be AddToDiv would throw an Exception and ParseDocument, which calls AddToDiv, could catch it and handle it.

Upvotes: 0

Related Questions