views:

492

answers:

6

In Java if an input argument to a method is invalid, we can throw an IllegalArgumentException (which is of type RuntimeException). In C++, there is no notion of checked and unchecked exceptions. Is there a similar exception in standard C++ which can be used to indicate a runtime exception? Or is there a common style not in the standard but everyone follows in practice for a situation like this?

Or, should I just create my own custom exception and throw it?

+1  A: 

std::domain_error may be what you are looking for, but I suspect very few people use it. Most people derive their own exception types from std::exception.

anon
+1  A: 

If by invalid you mean doesn't satisfied method expected values you can throw

std::logic_error 
or 
std::runtime_error.

If you mean something related to casts like one object can't be converted to another - there is no exception for that and it won't be thrown automatically.

In fact it will. But only for dynamic_cast<> on references. It will throw

std::bad_cast

I am not sure it is a good idea to throw this one by your own.

I prefer to use logic_error and its derivatives in case someone passed wrong parameter because it is a logic error: programmer passed wrong type of argument.

But more of all I like to use assert in such cases. Because such things like passing wrong values or types to your function can be acceptable only during development and such checks should be avoided in the release.

Mykola Golubyev
Does dynamic_cast<>() with a reference type throw a standard exception?
Tom Hawtin - tackline
It does, a std::bad_cast exception. If it is with references. With pointers a 0 is returned and the user code must check the result value.
David Rodríguez - dribeas
Yeah, std::bad_cast.
Mykola Golubyev
+1  A: 

I always use std::invalid_argument for illegal arguments.

rlbond
+14  A: 

Unlike Java, C++ does not have a "standard framework" but only a small (and optional) standard library. Moreover, there are different opinions under C++ programmers whether to use exceptions at all.

Therefore you will find different recommendations by different people: Some like to use exception types from the standard library, some libraries (e.g. Poco) use a custom exception hierarchy (derived from std::exception), and others don't use exceptions at all (e.g. Qt).

If you want to stick to the standard library, there exists a specialized exception type: invalid_argument (extends logic_error).

#include <stdexcept>

// ...
throw std::invalid_argument("...");

For the reference: Here is an overview of standard exception types defined (and documented) in stdexcept:

exception
    logic_error
        domain_error
        invalid_argument
        length_error
        out_of_range
    runtime_error
        range_error
        overflow_error
        underflow_error
Ferdinand Beyer
+1  A: 

You can throw a standard exception or roll your own. You may want to include additional information in the exception you're throwing, and that would be a good reason to do your own.

Personally, I haven't seen such domain checking in systems I've worked on. It certainly isn't universal.

David Thornley
A: 

Theoretically, I believe one should avoid throwing exceptions because of illegal parameters, unless these parameters are derived from user input. The (theoretical) reason is, illegal parameters are a programmer error and as such should be trapped during the development process.

In practice, however, you cannot expect, especially when working with a large legacy code base, to cover 100% of your program during testing. There is therefore a risk that code passing illegal inputs will be run only in production, not during testing. Then it may be more convenient for you to have an exception thrown, caught and logged, or whatever. You have to use your judgement here. For example, if I was coding a routine which controls expensive automated equipment, I would not be above inserting run-time checks for the correctness of inputs into release code, even if it could be seen as defensive programming.

quant_dev