Difference between catch block and throw new Exception in method

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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"

Answer 4

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.

Answer 5

Ah, makes sense.

Funnily enough, I ignored the possibility of checking for existance with an if statement (e.g. if abc.contains(...)).

While on the topic of exceptions, if I use multiple objects in a method like a filestream and streamreade, how should I layout my catch chain?

E.G. If I use streamreader only I can have an exception if the document can't be found (I can't remember the exact type), and then my general exception (Exception type), but what if I have two or more objects each of which throw different exceptions?

Answer 6

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.