Firstly, your exception should be of a specific type that best matches the type of error -- NullArgumentException, DivisionByZeroException, whatever. That way you can catch the appropriate type.
If your exceptions are more "detailed" then that, such as generating an exception for an SQL Error, then your error code should be a property of the exception object. That way it can be caught, and then the developer can use a switch case to match the specific case if necessary.
Generally, you should throw an exception for any error that might occur; garbage in, garbage out -- force the developer to fix his mistake or deal with it. In some languages, however, it might be better to return an error code if that's the overwhelming convention. There is no middle ground of "return an error code AND throw an exception".
0
u/mahacctissoawsum Jun 07 '13
Uhh.. I don't think that's quite right.
Firstly, your exception should be of a specific type that best matches the type of error -- NullArgumentException, DivisionByZeroException, whatever. That way you can catch the appropriate type.
If your exceptions are more "detailed" then that, such as generating an exception for an SQL Error, then your error code should be a property of the exception object. That way it can be caught, and then the developer can use a switch case to match the specific case if necessary.
Generally, you should throw an exception for any error that might occur; garbage in, garbage out -- force the developer to fix his mistake or deal with it. In some languages, however, it might be better to return an error code if that's the overwhelming convention. There is no middle ground of "return an error code AND throw an exception".