What is the correct .NET exception to throw when try to insert a duplicate object into a collection?

I have an Asset object that has a property AssignedSoftware, which is a collection.

I want to make sure that the same piece of Software is not assigned to an Asset more than once. In Add method I check to see if the Software already exist, and if it does, I want to throw an exception.

Is there a standard .NET exception that I should be throwing? Or does best practices dictate I create my own custom exception?

From stackoverflow mattruma

• You should probably throw ArgumentException, as that is what the base library classes do.

  From Kris Erickson

• Well, if you really want an collection with unique items, you might want to take a look at the HashSet object (available in C# 3.0).

  Otherwise, there are two approaches that you can take:

  • Create a custom exception for your operation, just as you had stated
  • Implement an Add() method that returns a boolean result: true if the item is added and false if the item already has a duplicate in the collection

  Either approach can be considered best practice, just as long as you are consistent in its use.

  From Jon Limjap

• I always liked the InvalidOperationException. However, you could also create a custom exception, say a DuplicateSoftwareAssignmentException.

  Will : I hate you, downer.

  Will : "Throw an ArgumentException or create an exception derived from this class if invalid parameters are passed or detected. Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state." Suck it, downers.
  From Will

• .Net will throw a System.ArgumentException if you try to add an item to a hashtable twice with the same key value, so it doesnt look like there is anything more specific. You may want to write your own exception if you need something more specific.

  From DaveK

• From the Class Library design guidelines for errors (http://msdn.microsoft.com/en-us/library/8ey5ey87(VS.71).aspx):

  In most cases, use the predefined exception types. Only define new exception types for programmatic scenarios, where you expect users of your class library to catch exceptions of this new type and perform a programmatic action based on the exception type itself. This is in lieu of parsing the exception string, which would negatively impact performance and maintenance.

  ...

  Throw an ArgumentException or create an exception derived from this class if invalid parameters are passed or detected.

  Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state.

  This seems like an "Object state invalid" scenario to me, so I'd pick InvalidOperationException over ArgumentException: The parameters are valid, but not at this point in the objects life.

  mattruma : I do want to give the UI developer the opportunity to handle this specific error ... so I'm going to create my own exception type.

  Will : Hay! I said IOE or custom, and I didn't get the answer! Shenanigans!

  Rob Cooper : I disagree with this answer - see my answer below.
  From Adam Wright

• Why has IOE been accepted as the answer?! It should be an ArgumentException?!

  IOE should be used if the object having the method/property called against it is not able to cope with the request due to uninit'ed state etc. The problem here is not the object being Added to, but the object being passed to the object (it's a dupe). Think about it, if this Add call never took place, would the object still function as normal, YES!

  This should be an ArgumentException.

  StingyJack : +1 totally agree
  From Rob Cooper