tags:

views:

220

answers:

4

Imagine that you have a method with the following signature:

public void DoSomething(Guid id)

If Guid.Emtpy represents an illegal value, which Exception type would it be most appropriate to throw? ArgumentException or ArgumentOutOfRangeException?

I'm leaning slightly towards ArgumentException, since I don't think that all Guids except Guid.Empty is much of a range - it's a bit too inclusive: There is only one excluded member.

However, I am in no way determined that this should be the case, so I'd like to hear if anyone can provide arguments for one or the other?

I'm well aware that this is mainly a semantic discussion, but in the interest of good API design I'd still like to know whether there are clear cases for one or the other option.

+1  A: 

Throw an InvalidArgumentException. That exactly follows the semantics you're after. You wouldn't throw an ArgumentOutOfRangeException if you expect an uint and all values except 0xffffffff are valid, would you?

OregonGhost
The InvalidArgumentException is part of the Microsoft.SqlServer.Management.Common namespace. You wouldn't want to add a reference just to get access to that exception. Use ArgumentException instead, which is in the System namespace.
Guffa
You are absolutely right. I just could have sworn that I saw some InvalidArgumentException in straight BCL code, since I never used SqlServer...
OregonGhost
+6  A: 

I'd throw an ArgumentException. Its docs say:

The exception that is thrown when one of the arguments provided to a method is not valid.

which is exactly the scenario you describe. You want something along the lines of:

throw new ArgumentException("Guid.Empty is not a valid id", "id");
adrianbanks
+2  A: 

Saying that an empty value is out of range just seems wrong. As Guid.Empty is usually used when there is no defined value at all, there isn't really any value that can be outside of the range.

The situation is similar to when you use ArgumentNullException, except there is no specific exception for empty values. An ArgumentNullException would be misleading, so ArgumentException is a better fit.

Also consider if ApplicationException would be better. That's used for exceptions in the application rather than a class library.

Guffa
ApplicationException is a bit redundant and probably best avoided (http://stackoverflow.com/questions/52753/derive-from-exception-or-applicationexception-in-net).
adrianbanks
@adrianbansk: That's about deriving from Exception classes, which is only barely related. If you don't want to use a specific system exception so that you can catch it along with other system exceptions, an ApplicationException works just fine.
Guffa
Yes, I know. What I was getting at is that if ApplicationException is regarded as "should not be part of the .Net Framework" by many, then it's use may be deprecated in future. Avoiding its use now for a more relevant ArgumentException would avoid this problem later.
adrianbanks
Throwing an ApplicationException is always the wrong thing to do. Please read this article: http://cuttingedge.it/blogs/steven/pivot/entry.php?id=56. Besides that, Mark is checking an method argument, so he should throw an ArgumentException or one of its descendants.
Steven
A: 

AE.

Exactly what is the acceptable range of Guids your method is expecting?

Is CA72EE5A-5F26-11DE-BD28-13A156D89593 within the acceptable range, but D58B3112-5F26-11DE-B0D2-5FA156D89593 is right out?

Will
I think the acceptable range is 00000000-0000-0000-0000-000000000001to FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF. Therefore, I think we can conclude that Mark should throw an ArgumentOutOfRangeException, because there is only a single value that is invalid. He should throw an InvalidSingleArgumentValueException, but because this exception doesn't exist, I'd go for ArgumentException :-)
Steven