Try...Catch... Resume??

[Rob R. Ainscough]

In VB6 I can use Resume Next to execute the line of coding following the
line that cause an exception. There doesn't appear to be anything similiar
when using Try...Catch -- so how can one resume the next statement when an
error can be ignored?

Thanks, Rob.

 

[Patrice]

On error resume next is still there (AFAIK actually it uses try/catch behind
the scene) or just catch only the block of statement you need (a single
statement if you really need).

You could also describe the exact problem (for example in some cases, you
can test if the argument would result in an exception rather than to catch
an exception that would be caused by the incorrect argument).

 

[Cor Ligthert [MVP]]

Rob,

Because that in this newsgroup not everybody knows about VB6 can you show
that Try Catch statement completely as you use it in VB6.

Thanks,

Cor

 

[ThunderMusic]

one way to do so is put many try...catch structures in your method, and
putting your stuff into blocks... when having a line that could cause an
error that can be ignored, place this line (and only this one) in the try
part of the try...catch, then continue...

Maybe there is another solution, but this one works...

ThunderMusic

 

[Guest]

Rob,

I think that if you change the scope of the try...catch you will find that
you can accomplish what you are looking for. Take the following pseudo code
for example...

Try
For x = 1 to 100
' Do something that causes an error occasionally.
Next
Catch Exception


Using the preceding exception handling you cannot return to the loop to
continue. But if you simply change it to:

For x = 1 to 100
Try
' Do something that causes an error occasionally.
Catch Exception
Next

You're code can continue to work on the loop. When you catch exceptions you
want to keep it to the smallest scope possible and want to catch the most
specific exception possible. By this I mean, assume that you are using
File.Copy to copy a file. Looking in the MSDN documentation you can see that
it can throw 8 different exception types. You may be tempted to catch
System.Exception just to have one catch block but with a little forethought
you do not need to worry about all 8 of them. You can check the arguments
that you pass in before to make sure that they are valid and eliminate the
possibility of it throwing ArgumentException, ArgumentNullException,
DirectoryNotFoundException, FileNotFoundException, and NotSupportedOption.
If you have checked for permissions or used code access security to specify
your permissions you can avoid the UnuathorizedAccessException. Thus, you
would just need to catch the IOException which you can not really plan around
since you cannot know ahead of time if your hard drive is going to crash.

I hope this long winded answer is close to what you were looking for.

Michael

 

[Rob R. Ainscough]

I was hoping to avoid using many Try ... Catch constructs repeatedly. What
I'm trying to accomplish is basically ignore an element error when reading
thru an XML file -- if the element isn't in the file just continue reading
and ignore -- this allows me to work with XML structures that change where
I'm only interested in certain parts of the XML file.

MSDN states that I can't use a Resume statement in a Try...Catch -- either
use one approach or the other. I like the Try..Catch construct, but I was
hoping that I wouldn't loose my Resume functionality. .NET still supports
the On Error ... Resume so I guess I'll have to use that for this instances.

thanks, Rob.

 

[Guest]

I do this all the time, just make your readElement call a function with a try
catch block in that function, if element is not there just return empty
string. Pass in xPath and elementName, return a string.

 

[Patrice]

What is the method you are using to read the XML file ? IMO having a missing
optional element shouldn't raise an exception as this is not an unexpected
situation.