Is it better to use Try or to use Resume Next?

[academic]

Sometime I have a situation where if an exception occurs I just want to
ignore and continue.

Is it better to use Try or to use Resume Next?



Or something else?

Thanks

Private Sub MenuItemPrevNode_Click(ByVal .snip..

Try

...A statement here

Catch

End Try

End Sub

 

[Patrice]

I would use Try for consistency but I would check first that I'm really
forced to do that. In particular can't you just do a test and quit the sub ?
Do you really have some unpredictable error you would like to ignore ?

 

[Carlos J. Quintero [VB MVP]]

Hi,

If you have only one statement whose exceptions you want to ignore, use the
Try/Catch block.

If there are several statements that you want to execute even if one of them
fails, use the On Error Resume Next statement. Doing the same with Try/Catch
would require one block for each statement, which for a large number of
statements is overkill.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com

 

[academic]

thanks

Hi,

If you have only one statement whose exceptions you want to ignore, use
the Try/Catch block.

If there are several statements that you want to execute even if one of
them fails, use the On Error Resume Next statement. Doing the same with
Try/Catch would require one block for each statement, which for a large
number of statements is overkill.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com

 

[academic]

Actually I could do

if TreeViewFolders.SelectedNode.NextNode isnot nothing then


would that be better in some way?

thanks

 

[Patrice]

Yes IMO it's much cleaner :

1) when reading the code in few month, you won't necessarily remember why
you ignored errors (even harder for someone else). With an explicit test
you'll see at once that you don't perform this if you don't have a next
node...

2) if you have any other kind of error, it will be ignored too

IMHO you should never never run code that you know will cause an error.
Instead just don't call the code that would lead to this error...

Patrice
--

 

[academic]

sounds good
thanks

Yes IMO it's much cleaner :

1) when reading the code in few month, you won't necessarily remember why
you ignored errors (even harder for someone else). With an explicit test
you'll see at once that you don't perform this if you don't have a next
node...

2) if you have any other kind of error, it will be ignored too

IMHO you should never never run code that you know will cause an error.
Instead just don't call the code that would lead to this error...

Patrice

 

[Jim Wooley]

Actually I could do

if TreeViewFolders.SelectedNode.NextNode isnot nothing then

would that be better in some way?

Checking for expected invalid values is always prefered over just trying
to use something that doesn't exist and trap it in an exception handler.
The framework is full of type checking even for simple expression evaluators.
The performance hit for checking is insignificant to the hit for throwing
and handling an exception. My favorite analogy holds: Don't pee in your pants
to check to see if your fly is open.

Jim Wooley

 

[academic]

ok

thanks

Checking for expected invalid values is always prefered over just trying
to use something that doesn't exist and trap it in an exception handler.
The framework is full of type checking even for simple expression
evaluators. The performance hit for checking is insignificant to the hit
for throwing and handling an exception. My favorite analogy holds: Don't
pee in your pants to check to see if your fly is open.

Jim Wooley