What are the pros and cons of error handling at beginning vs. end of the method

In my programmer's experience, I have mixed error handling all the ways possible... I have created my personal style.

However, I'd like to hear what you consider to be the pro and cons of error handling at the beginning vs at the end of the method.

Handling at the beginning:

public String GenerateSomeStringData(String data, int value)
{
    if (data == null)
        throw new ArgumentNullException("data");

    if (value <= 0)
        throw new ArgumentException("value must be greater than zero");

    int dataValue;
    if (!int.TryParse(data, out dataValue))
        throw new InvalidOperationException("data does not contain an integer");开发者_C百科

    return dataValue * 4 + value / 12;
}

Handling at the end: (the same example)

public String GenerateSomeStringData(String data, int value)
{
    if (data != null)
    {
        if (value > 0) 
        {
            int dataValue;
            if (int.TryParse(data, out dataValue))
            {
                return dataValue * 4 + value / 12;
            }
            else 
                throw new InvalidOperationException("data does not contain an integer");
        }
        else 
            throw new ArgumentException("value must be greater than zero");
    }
    else 
        throw new ArgumentNullException("data");
}

What criteria do you use when deciding how to approach this? Readability, maintainability, brevity?

Validity of input should be a precondition for execution of the method - as such I would (and do) always do the error handling first.

This has the following advantages:

• It is easier to parse for a human: validating preconditions first, then execution logic (which usually results in some post condition)

• Clear separation of concerns between error handling and execution logic
  within your method: validation logic is not "sprinkled in" within the execution logic

As mentioned in the comments you have to differentiate between invalid input that violates a precondition and triggers an error condition (such as throwing an exception) and valid input that constitutes an edge condition (i.e. requiring some special logic to handle). The later case I would handle separately after asserting the preconditions, at the beginning of the execution logic of your method.

As others have mentioned, I would check for input validity before executing any core logic of the method. Not only does this make logical sense but it also reduces the levels of indentation of your code and guarantees you don't have any if {} statements that are so long you can't see the else on one screen

The first method is much better.

It helps you keep all your validations in one place. You could even write a generic function to handle this type of validations.

Definitely more readability. You are done with all your validations in the beginning so you could go about your actual logic.

If your code spans a little bit more, it will be tough to track down the closing parentheses of the if loops.

My opinion is: do error condition check first for clear definition for someone else about what is OK for your method and what is NOT ok.