Which .NET exception to throw for invalid database state?

I am writing some data access code and I want to check for potentially "invalid" data states in the database. For instance, I am returning a widget out of the database and I only expect one. If I get two, I want to throw an exception. Even though r开发者_Python百科eferential integrity should prevent this from occurring, I do not want to depend on the DBAs never changing the schema (to clarify this, if the primary key constraint is removed and I get a dupe, I want to break quickly and clearly).

I would like to use the System.IO.InvalidDataException, except that I am not dealing with a file stream so it would be misleading. I ended up going with a generic applicationexception. Anyone have a better idea?

InvalidDataException seems pretty reasonable to me:

• The name fits perfectly
• The description fits pretty reasonably when you consider that it's effectively a data "stream" from the database
• Nothing in the description mentions files, so I wouldn't be worried about that side of things

You're effectively deserializing data from a store. It happens to be an RDBMS, but that's relatively unimportant. The data is invalid, so InvalidDataException fits well.

To put it another way - if you were loading the data from a file, would you use InvalidDataException? Assuming you would, why should it matter where the data is coming from, in terms of the exception being thrown?

If you need an exception that would exactly describe the situation you're dealing with, why not make your own exception?

Just inherit it from System.Exception.

I might be tempted to use one of the following:

InvalidConstraintException
NotSupportedException
OverflowException

Or, just go ahead and create my own: TooManyRowsException

You could write a custom exception if you do not find any suitable standard-exception ...

But, you say:

Even though referential integrity should prevent this from occurring, I do not want to depend on the DBAs never changing the schema.

When someone changes the DB schema, changes are pretty big that you'll have to make some modifications to your application / data-access code as well ...