2

Not sure how much of the code is necessary here. I'm trying to create a try block that doesn't include all of my code for handling the XML file. If I can't read the XML file, I get an UnauthorizedAccessException exception here:

XmlReader xmlIn = XmlReader.Create(configFile, settings);

But then I have all of my code that reads the XML and because the xmlIn is in the Try block, the rest of the code in my method can't see it. I thought about maybe creating a default XmlReader:

XmlReader xmlIn = null;

Before the try block and just throw the initialization in the try block, but the method is supposed to return a custom object that contains some strings and that causes the code that is supposed to run after that part to throw a NullReferenceException exception.

I searched for a while and the best I could come up with was the following that suggested that it's better to handle the exception, rather than testing access to the file beforehand, which is what I was thinking to try: how can you easily check if access is denied for a file in .NET?

So I'm kind of stuck in the middle with the proper way to handle this code that I thought would be pretty trivial. Do I just throw everything in the method into a try block, use the try in the part of my code that calls this method, or is there a better way to handle this?

Community
  • 1
  • 1
LazarusG
  • 150
  • 1
  • 5
  • 16

1 Answers1

0
 XmlReader reader=null;
    try
    {
          //reader.Create code
    }
    catch
    {
        //your exception code
    }

    if(reader!=null)
    {
        //other tasks
    }
Victor Mukherjee
  • 10,487
  • 16
  • 54
  • 97
  • Okay, so all of my tasks involving the reader should be within the try block, even if I'm reading a bunch of elements from the XML? – LazarusG May 18 '13 at 06:22
  • Sorry, let me add a little more to that. All of the "Best Practice" information I have read always has a very small amount of code or a method in the try block. I guess I'm just not sure how much code is too much for a try block because of the possibility of other unexpected exceptions being thrown in there. – LazarusG May 18 '13 at 06:27
  • the problem is that when your code encounters reader after try block, compiler throws error because all of the code paths have not initialized the variable. Hence, you will have to assign null to the variable initially. I cannot say about the best practices, but this will work. – Victor Mukherjee May 18 '13 at 06:29
  • Generally speaking, best practice is to use try catch blocks to handle code where something **unexpected** can happen and there is no way programatically to deal with it in a preventive/graceful manner. A common example of this is opening a file - you can check to see if the file exists before trying to open, so wrapping the File.Open in a try-catch block simply to handle the file not being there is considered bad practice. If you look on MSDN for the objects you're using, you'll usually see a list of exceptions they will/can throw and what causes them. – Tim May 18 '13 at 06:32