Error Checking (1 Viewer)

[Thales750]

I almost never us error checking, other than using "Resume on Error", which is in extremely rare occasions is the only way to get the code to run.

In millions of executions, I don't remember a single indecent that error checking would have made any differences.
Just continuing to cultivate my pariah persona. What are your thoughts?

 

[theDBguy]

It's highly recommended and considered best practice to include error handlers in most of your code.

 

[Thales750]

It's highly recommended and considered best practice to include error handlers in most of your code.

I'm into the hundreds of thousands of lines, millions of execution, millions of records. So far, not one problem. So why?

 

[Pat Hartman]

almost never us error checking

I wouldn't be proud of that.

If you distribute an .accde/.accdr or run with the runtime and an unhandled error arises. Access simply closes. How's that for user friendly? If you distribute an .accdb, the user is likely to be just dropped into a code module. That's great also.

I'm into the hundreds of thousands of lines, millions of execution, millions of records. So far, not one problem. So why?

If you just Resume Next, how would you know that there were any errors?

 

[Thales750]

In the interest of not being a complete undesirable, I do remark my code.

 

[Gasman]

It would have been nice if Access generated the basic structure for error handling when a sub or function was created. Might have led to more use with novices.

 

[Thales750]

I wouldn't be proud of that.

If you distribute an .accde/.accdr or run with the runtime and an unhandled error arises. Access simply closes. How's that for user friendly? If you distribute an .accdb, the user is likely to be just dropped into a code module. That's great also.

The only way I deliver is compiled. 25 years later, still no problems. I think it's a myth.

 

[pbaldy]

Add me to the list of people using error handling (most of the time). With MZ Tools it's a right-click away. I only use Resume Next in very rare circumstances, like when deleting an object that may or may not exist.

 

[MajP]

I think it's a myth.

I am closer to you in that opinion. I purposely do very little error handling. When I do add it, it is deliberate and thought out. For sure I never write code with error checking to start with, unless I know there is a vector that could cause a failure and I cannot prevent it. That is not a lot. I try to write bullet proof code, and I want to test it and find all the ways it can fail and try to account for those. Then only after a lot of demos and usage will I consider putting in error handling. I use MZTOOLS which makes adding error handling after the fact pretty easy. I write a lot of VBA so it is obvious to me if there is any possibility that a run time error can occur.
When people say you need error checking in all procedures, I think that is silly. If there is code that cannot possibly fail then why add error checking. I only write error handling where I know an error could occur and usually that is specific to certain errors. In fact when I see others with random error handling, I wonder if they understand their code.

 

[Thales750]

When people say you need error checking in all procedures, I think that is silly.

I do exactly what you say. I write code that does not break, test it to exhaustion, and then be there for the client if it fails. Usually it will fail during testing, I encourage the clients to use their best key board bashers. Like you, I wan't it to fail.

I would actually like to hear stories of why people write error code. I think "we've always done it this way" is the real reason.

 

[MajP]

I would actually like to hear stories of why people write error code. I think "we've always done it this way" is the real reason.

It is the same with the dogmatic belief that you need to set objects to nothing or bad things are going to happen. I see this often on this forum when someone has an issue with a piece of code and the answer is you did not set your objects to nothing. If you ask them why they cannot answer. Maybe .5% of the time I set an object to nothing and when I do I have a reason. Yes it is also a myth, and yes it is based on "it is what I have always done".

Here is a great discussion on that.

When Are You Required To Set Objects To Nothing?

docs.microsoft.com

I do not have an issue with people who over use it, heck you can wear a belt and suspenders if that makes you feel better. It just bothers me when more experienced people on this site blindly state it.

 

[The_Doc_Man]

On the "set objects to nothing" viewpoint, we had a discussion some time ago regarding the need to cause recordsets to close, optionally followed by setting them to nothing in certain cases dealing with SMB v2 or v3 because of the "reserved buffer" bug/feature. The "Close" was the critical part. Didn't matter about releasing the implied data structure later. It was a Microsoft product person who provided us with links to the articles that said there were specific times when you should not trust the automatic reclamation that occurs after an End Sub. There is also the point that whether you set it to Nothing or not, there are certain app objects that you MUST force to quit/exit because the app objects have a life that is parallel to rather than subservient to the Access parent process.

I will state clearly that as a matter of trying to avoid regaining a bad habit, I set object variables to nothing in VBA after closing them. However, my motive is to avoid getting into that bad habit in other languages that aren't as forgiving as VBA about automatic object reclamation. Also, since I tend to make some objects Public, testing to see if they are Nothing is useful as a flag, so I set the objects to Nothing when I don't want the current or most recent instantiation re-used (to avoid accidents to something left open).

As to writing error code, there are times when I let something run without traps, but if you are using Outlook, there are cases where you will get an error 287 (Application-defined error) where the correct conclusion is to "Resume Next" - but other errors need to be handled in order to avoid getting trapped into the Access "Last Chance" handler. If using CDO, you probably need to have trap handlers in place to test for errors.

If you are dealing with user inputs, error handling is probably a good idea because users tend to be the best bug-finders in the known universe. Or at least the U.S. Dept. of Defense civil service folks were good at it. Where we couldn't provide drop-downs of any kind because input had to be free-form, folks found ways to screw up 2+2. Stated another way, artificial intelligence cannot cope with natural stupidity.

 

[Steve R.]

I almost never us error checking, other than using "Resume on Error", which is in extremely rare occasions is the only way to get the code to run.

In millions of executions, I don't remember a single indecent that error checking would have made any differences.
Just continuing to cultivate my pariah persona. What are your thoughts?

Your focus appears to be on the code itself, but there is more to "error checking". For me, "error checking" also involves examining the data for validity as it is being entered. Is the data within reasonable bounds? If the data being entered is invalid, then it raises the old adage "garbage in, garbage out". With inaccurate data, the validity of the database comes into question.

 

[Thales750]

Your focus appears to be on the code itself, but there is more to "error checking". For me, "error checking" also involves examining the data for validity as it is being entered. Is the data within reasonable bounds? If the data being entered is invalid, then it raises the old adage "garbage in, garbage out". With inaccurate data, the validity of the database comes into question.

As you and Doc just mentioned, I use validation all the time, in one form or another. I couldn't agree more about that.

 

[Sun_Force]

@Thales750 @MajP

the problem is, you have had gentle users and they never tried to bring down your app.
You will never know how a user acts.


I really appreciate Microsoft programmers are not confident with their abilities like some members here and do excessive error handling.
Otherwise I would have faced the blue death screen every 5 minutes.

 

[The_Doc_Man]

Oh, I'm very confident. Confident that error checking is a good idea 'cause I'm a klutz.

 

[Isaac]

I'm into the hundreds of thousands of lines, millions of execution, millions of records. So far, not one problem. So why?

that's funny. and frankly, absolutely ridiculous not to have it. no serious coder doesn't have it.

the main bad things that happen because of not having error handling are things you never realize are happening.

your post is living proof.

that's like saying: "I close my eyes and drive a tank into a crowd of people. Then I open them once I'm done. So far, no problems that I can see"

 

[Isaac]

When people say you need error checking in all procedures

all non-trivial procedures is the more common quote

 

[Isaac]

The only way I deliver is compiled. 25 years later, still no problems. I think it's a myth.

nope. anyone on this thread can try it now. create a proc that will generate a run time error. open the db as accdr. the database will say execution cannot continue and this application will shut down. every time. myths aren't easily provable as true in the space of 30 seconds.

 

[pbaldy]

My memory is hazy, but it may be that an unhandled error will blow up an application being used with the runtime version, not necessarily just an accde. Your use of accdr lends credence to that, but again I'm not sure.