I am having an ArgumentException with a ResxResourceReader.
I know the file exists, however I can't know if the contents of the file are appropriate (it has a .resx extension but the contents may be rubbish or there can be no contents at all).
The question is how can I check that it is a proper resource file without enumerating it? Since enumerating it with reader.GetEnumerator() throws the exception.
I've looked at the properties of the reader but didn't see anything that would allow me to do that.
I could do a try and just catch the exception but I want to avoid that if possible.
Any suggestions?
[EDIT] I want to avoid a try-catch specially because on the catch I would be doing the same operation with another resx file, and if that is invalid aswell... well you get what I mean. Though this should seldomly happen.
This is not 100% answer to the question, but will address your reason for the approach you are asking for.
If you are concerned about the performance, there is a good reason to use cached ResourceManager (hold a static instance), which can try to refresh itself in the background asynchronously (every 1 minute or so) and not to be bound to each request. If it fails, it will fail once a minute. If it does not fail, all worker threads will be able to access the new resources.
This is of course if the business rules allows that. Should I use the static cached ResourceManager or a new instance for each web request? Does it matter? In the CATCH, you can just use a 'fallback cached instance', so no second read operation occurs.
The idea to do the heavy operations asynchronously is the way to go, when designing applications for heavy load/low resource in mind - try to keep the "main loop" as clean as possible.
Besides that, it depends what you would want to check. You certainly can check the file content in a different ways, but the IO cost for reading the physical file (twice) will be waaaaaay more expensive than the actual TRY/CATCH. Using Exceptions throwing in C#. Does it affect a performance? TRY/CATCH-es are not free, but they are for a reason, and sometimes you can not avoid them. They are a safety-net so the whole application continues to function.