Everyone is entitled to their opinion, and now, you are the second person
that I've come accross that thhinks differently. I imagine there are
probably many others who would use it as well.
My definition of this is simple...
On Error... If an error occurs
Resume Next... Don't worry about it
To me (IMHO) equates to... Poor Programming Practices.
Lets say you are working on a large system and this was allowed to be used
by all who worked on the system (bad idea). Now lets say that it ignored an
error that caused the system to not correctly calculate something. Now lets
say this calculation was something that people made business decisions on,
or this was information that you are providing to your clients and expected
to be correct. You may have several developers working on this system all
using this practice.
If you do not see the potential for disaster here... I don't know what more
I can say. Sure a properly handled exception is important, but even a poorly
handled exception would at least be trapped and display something to the
user. And that is much better than having an exception that no one knows
about until it becomes a disaster.
I have seen it happen, and understand why it is looked down upon. This is
just my opinion, but I think I'll stick with it. Those who choose to use it
have every right to do so, but when it comes back and takes a big bite out
of your butt... Don't say I did'nt try to warn ya...
Best Regards
Bob Calvanese
"Thief_" wrote in message
...
I agree with Bob Phillips on this point. I just recently got into the exact
same discussion on a VB/VB.Net form. ALL error handlers are prone to being
"not a good programming practice" if not coded correctly. And furthermore,
if MS decided to include "On Error Resume Next" compatability in Dot Net
2003, but not provide a "Try....Catch" equivalent, then there's browney
points too. Here's an example:
Sub ShowBadErrorPractice()
On Error GoTo ErrorHandler
Set NonExistantSheet = Worksheets("ThisWorkSheetDoesntExist")
' BLAH
' BLAH
' BLAH
' BLAH
Exit Sub
ErrorHandler:
Select Case Err.Number
Case 1000
' BLAH
Case 1001
' BLAH
Case 1002
' BLAH
End Select
' WHAT@!? No error 9 handling???
End Sub
The best example of the use of "On Error Resume Next" which I use a lot of
is with Dynamic Ranges:
On Error Resume Next
If lbWS.Tag = "Select All" Then
Worksheets("Summary").Range("DataRange").Clear
' Error 1004 "Application-defined or object-defined error" will occur
if
the
' Summary ws is already clear and the name range defines to an illegal
address (it's dynamic!)
On Error GoTo 0
Now, show me a better method of clearing a dynamic range using not more
than
two lines of code!
Every Error routine is only as good as the person who programmed it. If
you
are going to use an "On Error Resume Next", it has got to be placed right
where you expect the error to occur and right after the code which "could"
produce an error, you need to have you error checking/correcting code.
--
|
+--Thief_
|
"rcalvanese" wrote in message
...
When I went to school, If we used On Error Resume Next anywhere in our
code,
we had points taken off our GPA. Some people may have a different
oppinion,
but in my oppinion... It is a poor programing practice. And any place
that
I've worked so far that does VB/VBA looks down upon it as well. In
fact...
You are the first person I've run accross who seems to think other wise.
Best Regards,
Bob Calvanese
"Bob Phillips" wrote in message
...
"rcalvanese" wrote in message
...
"On Error Resume Next" is not a good programming practice.
That is far too general a statement.
You want to "handle erreors" not "ignore them".
In many cases, On Error Resume Next is helping to handle errors. For
example
On Error Resume Next
Set sh = Worksheets("somename")
On Error Goto 0
If sh Is Nothing Then
Worksheets.Add.Name = "somename"
End If