Question: Suppose a simple example where a method retrieves a collection (such as a list containing some configuration strings) and tries to examine it in some way:

```
void Init()
{
    XmlDocument config = new XmlDocument();
    config.Load(someXml);
    var list = config.SelectNodes("/root/strings/key"); // Normally, list should not be null or empty

    if (list == null || list.Count == 0)
        throw new SomeExceptionType(message);   // What kind of exception to throw?

    // Iterate list and process/examine its elements
    foreach (var e in list) ...
}

```

In this specific instance, the method cannot continue normally if nothing was retrieved. I'm unsure what exception type to throw in such situations. My options are, as far as I know:

* throw nothing manually and let `NullReferenceException` be thrown
automatically (which doesn't handle empty list situation),
* throw custom exception type (probably not a good idea, as I don't anticipate the caller will try to do anything about the exception,
i.e. he won't be looking for a speecific exception type to handle),
* do something else?

Answer: 
`Enumerable.First` throws `System.InvalidOperationException` if the collection is empty. So could you, I guess.

```
throw new InvalidOperationException("Sequence contains no elements");

```

<https://learn.microsoft.com/en-us/dotnet/api/system.linq.enumerable.first?view=netframework-4.8>
I'm not sure there is a single built-in exception you can elegantly throw in this case...a `NullReferenceException` is inappropriate since an empty list is not a null reference

I would suggest going with Dmintry's proposed solution since the caller can still just use `try...catch(Exception)` without having to know or care that the exception is really a `SuperDooperListNullOrEmptyFunTimeException`

Since this is either an unrecoverable error from the caller's point of view (i.e they have no control over the selected Xml path, and no control over what the XML is that's being loaded) then the exception is only going to be either dumped to a log or on-screen for human consumption, at which point it's moot - as the actual message is more important than the type.

On the other hand, if it is recoverable (caller can re-try the method after having made sure that the xml to load now contains the correctly formatted xml, or caller can notify the user and ask them to go and fix the XML and "would you like to retry now?" kind of thing) then you *need* to give them a typed exception so they know it's safe to retry as opposed to a plain old Exception which could mean something else went horribly wrong and retrying will only make things worse...