Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.excel.programming
|
|||
|
|||
On Error Resume Next
I have been reading many posts where I see "On Error Resume Next" being used
As well as "On Error GoTo 0" (which basically disables the error handeling for the method). I was taught in school that this is a bad programming practice and if we used it in our projects, we would have points taken off our grade. When I began programming for a living, I noticed it was looked down upon by every IT Manager that I have ever met. One example that I can give is as follows: I was working for a telemarketing company who used VB5/VB6/VBA for just about all reporting because all cleint reporting was done in Excel. A client report that had been being run for about 6 months was calculating incorrectly. This calculation was used by our client to make business decissions and had been incorrect for the 6 months that the report was being run. I don't know all the details about the business end of it, but... Our company wound up having to eat 2 millin dollars. The IT manager went to the programmer who wrote the report and found that he had used On Error Resume Next in several places in his code. Upon commenting them all out and running the report, he was able to find the error that caused the calculation problem. Needles to say, the programmer was let go the next day. This is only my oppinion based on what I have learned and experienced thus far. To me it just sets a potential for dissaster. I have done a lot of Excel development over the years, but not in Excel itself. I choose to control excel automation from outside, and have developed some fairly large systems in VB6, and .NET. But it's just a prefference of mine not having to maintain all those proprietary macro's and having them attached to the spead sheet. So anyway... I see this being used pretty extensively here and would like to hear other oppinions as to why people would use this. Sure there are instances where you could save a few lines of code, but a programs effeciency is not measured by how few lines of code are used. And if there are exceptions in anything that I develop... I want to know about it. All oppinions welcome... Bob Calvanese |
#3
Posted to microsoft.public.excel.programming
|
|||
|
|||
On Error Resume Next
Thank you Nick for your input.
I would also like to add that anyone who is not sure of the potential risk involved here. Please... Do a little research and make up your own mind. I can only express my oppinion here, but I would hate to see someone get in a bad situation thinking that it was ok because they learned it on this news group. Bob Calvanese "Nick Hodge" wrote in message ... Bob The overall tenure of your statement is correct. In general On Error Resume Next is 'lazy' programming. It is used extensively here as most code is by way of example or code which is only run one or does very insignificant tasks. If this were not the case less answers would be given and people would be a lot more wary to do so, as they would have to write full error checking code each time. Seldom do problems of the magnitude you set out occur, in fact most of the time these statements purely stop the code from dropping out for trivial errors. (Chart sheet selected instead of worksheet, etc). Granted, it could happen the way you outline, but far more mistakes are made in functions and linking causing that type of anomaly than would ever be the case in code. All together, I agree, generally bad practice unless you know the outcomes you may get Just my £0.02 -- HTH Nick Hodge Microsoft MVP - Excel Southampton, England HIS "rcalvanese" wrote in message ... I have been reading many posts where I see "On Error Resume Next" being used As well as "On Error GoTo 0" (which basically disables the error handeling for the method). I was taught in school that this is a bad programming practice and if we used it in our projects, we would have points taken off our grade. When I began programming for a living, I noticed it was looked down upon by every IT Manager that I have ever met. One example that I can give is as follows: I was working for a telemarketing company who used VB5/VB6/VBA for just about all reporting because all cleint reporting was done in Excel. A client report that had been being run for about 6 months was calculating incorrectly. This calculation was used by our client to make business decissions and had been incorrect for the 6 months that the report was being run. I don't know all the details about the business end of it, but... Our company wound up having to eat 2 millin dollars. The IT manager went to the programmer who wrote the report and found that he had used On Error Resume Next in several places in his code. Upon commenting them all out and running the report, he was able to find the error that caused the calculation problem. Needles to say, the programmer was let go the next day. This is only my oppinion based on what I have learned and experienced thus far. To me it just sets a potential for dissaster. I have done a lot of Excel development over the years, but not in Excel itself. I choose to control excel automation from outside, and have developed some fairly large systems in VB6, and .NET. But it's just a prefference of mine not having to maintain all those proprietary macro's and having them attached to the spead sheet. So anyway... I see this being used pretty extensively here and would like to hear other oppinions as to why people would use this. Sure there are instances where you could save a few lines of code, but a programs effeciency is not measured by how few lines of code are used. And if there are exceptions in anything that I develop... I want to know about it. All oppinions welcome... Bob Calvanese |
#4
Posted to microsoft.public.excel.programming
|
|||
|
|||
On Error Resume Next
Error handlers are the most effective way to handle errors. It has
nothing to do with saving lines of code. For me, it is more a question of writing software that is self-documented, transparent in intent, and easy to both understand and maintain. Used correctly an error handler does all of that! True, rookie programmers tend to overuse error handlers and that can indeed lead to disasters of the magnitude you referred to. However, that has nothing to do with how the tool is used and everything to do with how it is abused. There is nothing intrinsically wrong with error handlers. When a developer uses one s/he assumes the responsibility to handle errors. If subsequently s/he shirks that responsibility, it is a people management problem. For anyone to conclude that the tool is flawed is -- to be blunt -- dumb. Do loops can be trouble, GoTos are frowned upon but can be great assets when used in limited circumstances. Personally, I find the single biggest source of poor systems is bad structural design. Too many managers, analysts, and lead programmers force their business application into the handful of structures they are familiar with -- the most 'advanced' data structure being an array. Not to mention the use of global variables. {shudder} People and organizations would be much better off if they invested in designing better algorithms, better data structures, and better programming methodologies and less time on mechanical rules about atomic language constructs. To state that error handlers lead to poor code reveals a lack of understanding on their value to *good* system design. They are no better or worse than, say, a do loop. Used properly they are very powerful aids. Used indiscriminately, like any other tool, they can be dangerous. I write error handlers where a function might raise an error that needs to be handled, or where I want to handle any error that might arise, or where I want to ignore errors. All other code is outside the scope of error handlers. In every case, the error handler *documents* my *intent* to handle errors; further, as the developer I am telling the OS I will handle errors -- or at *my* discretion ignore them. Obviously, if the software then does something dumb it becomes my responsibility. Would I have fired the programmer you mentioned in the incident you mentioned? Only if s/he had been made aware of the dangers of indiscriminate use of error handlers and trained in their correct use. I would have focused my attention on the manager who failed to properly train her/him. You wrote you have extensive experience with VB.Net. Given the enhancements available in it, I am surprised anyone would even question the value of error handlers. The Try...Catch...Finally structured error handler construct is just that -- a *structured* construct that clearly delineates the scope of the error(s) the programmer wants to assume responsibility for. A significant improvement over the unstructured VBA constructs, it is a capability that a good programmer should look forward to using. -- Regards, Tushar Mehta www.tushar-mehta.com Multi-disciplinary business expertise + Technology skills = Optimal solution to your business problem Recipient Microsoft MVP award 2000-2005 In article , says... I have been reading many posts where I see "On Error Resume Next" being used As well as "On Error GoTo 0" (which basically disables the error handeling for the method). I was taught in school that this is a bad programming practice and if we used it in our projects, we would have points taken off our grade. When I began programming for a living, I noticed it was looked down upon by every IT Manager that I have ever met. One example that I can give is as follows: I was working for a telemarketing company who used VB5/VB6/VBA for just about all reporting because all cleint reporting was done in Excel. A client report that had been being run for about 6 months was calculating incorrectly. This calculation was used by our client to make business decissions and had been incorrect for the 6 months that the report was being run. I don't know all the details about the business end of it, but... Our company wound up having to eat 2 millin dollars. The IT manager went to the programmer who wrote the report and found that he had used On Error Resume Next in several places in his code. Upon commenting them all out and running the report, he was able to find the error that caused the calculation problem. Needles to say, the programmer was let go the next day. This is only my oppinion based on what I have learned and experienced thus far. To me it just sets a potential for dissaster. I have done a lot of Excel development over the years, but not in Excel itself. I choose to control excel automation from outside, and have developed some fairly large systems in VB6, and .NET. But it's just a prefference of mine not having to maintain all those proprietary macro's and having them attached to the spead sheet. So anyway... I see this being used pretty extensively here and would like to hear other oppinions as to why people would use this. Sure there are instances where you could save a few lines of code, but a programs effeciency is not measured by how few lines of code are used. And if there are exceptions in anything that I develop... I want to know about it. All oppinions welcome... Bob Calvanese |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
On Error Resume Next | Excel Programming | |||
On Error Resume Next | Excel Programming | |||
ON ERROR RESUME NEXT | Excel Programming | |||
On Error Resume Next | Excel Programming | |||
On Error Resume Next | Excel Programming |