Best way to impliment a try catch block?

I want to put a try catch block around  line 48 below. Is that correct, or should I instead put a try catch block around lines 48 through 60?

 48      xmldoc.Load(filepath)
 49      rootNode = xmldoc.SelectSingleNode("//Clients")
 50        For Each clientnode As XmlNode In rootNode.ChildNodes        
 51          For Each environmentnode As XmlNode In clientnode.ChildNodes
 52            currentRow = tblSachelDatabase.NewRow
 53            For Each childnode As XmlNode In environmentnode.ChildNodes
 54              currentRow(childnode.Name) = childnode.InnerText
 55            Next
 56              currentRow("Client") = clientnode.Attributes("name").Value
 57              currentRow("Environment") = environmentnode.Attributes("name").Value
 58              tblSachelDatabase.Rows.Add(currentRow)
 59          Next
 60         Next
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You could put it around just line 48 or around 48-60.  It never hurts to have error catching.
ste5anSenior DeveloperCommented:
It depends on the degree of clean code you want to achieve.

The entire XML loading should be moved to it's own method. There you can use one try-catch for the entire method body. But don't implement a general catch. Catch only known exceptions.
Agree with @ste5an

You should move that into a method and put a try/catch around the method and MessageBox.Show the exceptions if you are in the editing phase
käµfm³d 👽Commented:
A Try/Catch should, IMO, go at the lowest level at which you could expect to gracefully recover from (or log) an error. Your business requirements should (indirectly) guide how you structure your error handling. What would you anticipate doing if an error occurred? Logging? Recovery? Something else? You need to answer those questions (and possibly a couple more) in order to have clean error handling.
Jacques Bourgeois (James Burger)PresidentCommented:
Catching only line 48 would catch any problem with a missing file, a bad path, a problem with security or the likes.

But you also have to be prepared for a file that is corrupted in some way.

Personally, I would have 2 Try...Catch blocks. One for the opening of the file, and another one for everything else.

The type of exceptions that you get while opening a file and the ones you get while reading it are different. And usually, so is the way you will handle the error. So it makes sense to have a block for each.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.