Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When should I use a ThrowHelper method instead of throwing directly?

When is it appropriate to use a ThrowHelper method instead of throwing directly?

void MyMethod() {
    ...
    //throw new ArgumentNullException("paramName");
    ThrowArgumentNullException("paramName");
    ...
}
void ThrowArgumentNullException(string paramName) {
    throw new ArgumentNullException(paramName);
}

I've read that calling a ThrowHelper method (a method with the only purpouse of throwing an exception) instead of throwing directly should yield smaller bytecode.

This, and the obvious encapsulation (another layer of indirection), may be good reasons to not throw directly, at least in some scenarios.

Anyway, IMO the drawbacks are not insubstantial too.

  • A part of the (exceptional) control flow is hidden
  • Exceptions end up having a more cryptic stacktrace
  • the compiler (2.0) will not recognize that ThrowHelper calls are exit points from a method, hence some code-around is necessary.

My limited experience is that often the overall design gets worse.

int MyMethod(int i) {
    switch (i) {
        case 1:
            return 1;
        default:
            ThrowMyException();
    }
    return 0; // Unreachable (but needed) code
 }

This may partly be a matter of personal taste. Anyway what are your personal guidelines about this issue? Do you find it is a good idea to use ThrowHelpers for all those common tasks like method param validation (ThrowArgumentNullException(paramName) and such)? Am I missing something obvious on this issue?

Btw I'm trying not to mix this issue with the validation issue, e.g. a method like:

ThrowIfNameIsNullOrEmpty(name);
like image 291
smv Avatar asked Dec 30 '09 12:12

smv


People also ask

When should I throw exception Java?

Exceptions should be thrown when the contract between a method and its caller cannot be fulfilled. This is the usage identified in the Java™ Language Specification.

Why would you want to throw an exception?

Exceptions should be used for exceptional situations outside of the normal logic of a program. In the example program an out of range value is likely to be fairly common and should be dealt with using normal if-else type logic. (See the programming exercises.)

Is throwing exception good practice?

The short answer is NO. You would throw an exception if the application can't continue executing with the bad data. In your example, the logic is to display an error message on the front end and Option 2 is the cleaner method for achieving this requirement.

Should you use exceptions?

Exceptions should only be used in exceptional circumstances and therefore should be used sparingly. For example, it is correct to use an exception when you are attempting to access the Twitter API and do some processing because if this fails it is an exceptional circumstance.


1 Answers

My default approach is to throw directly from the exceptional code branch.

The DRY principle and the rule of 3 guides when I would wrap that in a method: if I find myself writing the same 'throw' code 3 or more times, I consider wrapping it in a helper method.

However, instead of a method that throws, it's much better to write a Factory Method that creates the desired Exception and then throw it from the original place:

public void DoStuff(string stuff)
{
    // Do something

    throw this.CreateException("Boo hiss!");
}

private MyException CreateException(string message)
{
    return new MyException(message);
}

This preserves the stack trace.

like image 88
Mark Seemann Avatar answered Oct 31 '22 17:10

Mark Seemann