Avoiding ArgumentException with a ResxResourceReader

Question

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.

You may first (manually, not using `XmlReader`; even a raw check with ` — Adriano Repetti, Jun 12 '15 at 08:47
@Amit There is quite a bit of debate. And performance is ***critical*** in my application with potentially millions of concurrent calls. So even if the exception is catched once in a while per use of the application, if the application is called millions of times then the exception is catched a few millions of times which involves a significant performance chunk. [Relevant link](http://stackoverflow.com/questions/161942/how-slow-are-net-exceptions) — Jose Luis, Jun 12 '15 at 08:52
What is the chance that the resx file is rubbish? 1/100? Is it from a user's input? — d.popov, Jun 12 '15 at 08:54
I agree but a complete parsing is _slow_ (again because you can't be sure unless you do it completely). It won't slow down one every million but every single call (because it will be done twice: one by you and one by ResxResourceReader - which is probably much faster than you). Unless 99.9% of times you get an invalid resx...catching exception is faster (but I'd measure...) — Adriano Repetti, Jun 12 '15 at 08:54
@d.popov Not from the user's input. The chance is fairly low. If there is ***really*** no choice I will do a try-catch. I am mainly looking for alternate routes. — Jose Luis, Jun 12 '15 at 08:54
If you have the control over the regx file, then you should not worry that much for the try/catch while reading it. 1.Make It Work, 2. Make It Right, 3.Make It Fast. You will probably save more time if you do not read it each time, but cache it - it it is not likely to change often — d.popov, Jun 12 '15 at 08:57
@d.popov Unfortunately I don't have control over it. It is the responsability of someone else. This is in case this someone else makes a mistake, in which case the application doesn't fall apart. — Jose Luis, Jun 12 '15 at 08:59

score 0 · Answer 1 · edited May 23 '17 at 12:05

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.

Avoiding ArgumentException with a ResxResourceReader

1 Answers1