When to throw argument exception in c#?

A philosophical problem

Please have a look at the code and the explanation below and help me.

namespace Exception
{
    public enum DocumentType
    {
        Unknown, Txt, Jpg
    }

    public class DocumentTypeHelper
    {
        public static DocumentTypeGet DocumentType(string filename)
        {
            //Should I throw exception

            ...
        }
    }
}

The question for me is, should I throw an ArgumentNullException when the input is null and/or an ArgumentException when the filename is not a valid filename which could mean empty or in some other way invalid.

I searched the web quite a bit without finding anything particularly useful. I found some interesting things, though. Here is what I found:

Exceptions should only be used for exceptional conditions.

Interpretation
I think, in my example, exceptional condition would map to exceptional inputs. Is null or an invalid path an exceptional input?

Conclusion

Since this is an API method, I do not know whether these cases are exceptional. It depends on the context, in which this method is used.

Exceptions should be thrown when a fundamental assumption of the method is found to be false

This stackoverflow post makes this interesting point and gives 2 somewhat strange examples. 

The first example says bool IsInstanceOfList(Object obj) should never throw an exception because the questions this code asks "is obj a instance of List" can never be invalidated. The question is therefore valid regardless of inputs. Therefore this method should not throw an exception.

I can agree with this example. The language is pretty clear about the fact that Null does not instantiate any class and therefore the answer to the question "is null a instance of List" is no, which maps to false.

The second example says bool HasMoreThan50Elements(List list) should throw an exception because the questions this code asks "has list more than 50 elements" can be invalidated because it is expecting list to contain a list and not null.

To some degree I do understand this but one could also argue, I think, the language is pretty clear about the fact that Null does not contain any elememts and therefore the answer to the question  "has null more than 50 elements" is no, which maps to false.

Although, I find the examples perfectly clear, I can at least apply this approach to my problem.

I think, my code asks the question "which DocumentType corresponds to filename". Unfortunately, this does not help me very much, because I do not know whether null or invalid filename should match to DocumentType.Unknown. But since it feels more natural to argue that the fundamental assumption of this code is that filename contains a filename rather that filename contains some string of null. So this gives at least an indication that an exception should be thrown.

Argument exceptions should show the programmer that he has done a stupid mistake

Eric Lippert mentions this when he talks about boneheaded exceptions. He argues that such exceptions show the developer a mistake that he could have prevented in the first place.

I think, this is again too much based on the context in which this method is used. I do not know whether the developer who is using my method is stupid when passing null or whether he is just dependent on some other framework which gives him a null. Maybe he is not at fault and could not have prevented this in the first place.


Don't use exceptions if the error can be handled locally

Again, I do not know whether it can be handled locally, since I do not know how it will be used. I assume it cannot be prevented locally. Unfortunately, It does not say: Use exceptions if the error cannot be handled locally.

Keep it simple, stupid

Does this mean simple in terms of not having any exceptions which add to the possible state space that is reached after calling this method, or, does it mean the developer should have a simple time searching for the bug?

What do you think?