Error Checking

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.
@MajP
I know you try. But for God's sake don't tell me you can. You are one of the best programmers I've ever seen (I'm young and only 3 years into PC world). but you can't be perfect.

The following errors are from the most expensive CAD application (Solidworks). Even programmers on that range can not be bullet proof.
Google Solid works funny errors for more:


12.jpg



V5KTUWe.jpeg



--------------------------------


VHjWLlW.jpeg
 
Last edited:
Just for being clear for the third image above :
Solidworks has no Address Bar at all.
 
When you run an .accdb and an unhandled error occurs, the VBA window opens up with the error line highlighted. That can't happen in an .accde since there is no source code left in the db.
 
We all try to write bulletproof code. I've written some CORRECT code - but it included error handling for things out of my control, such as bad user input. Even simple formulaic math code needs error handling if there is a chance to trigger any of the "divide by 0" or "exponentiate by negative" or other math pitfalls. Sometimes, the trick is not to trap after-the-fact but to intercept before-the-fact.

If you count the "interception" code as a form of error handling, then for ANY code susceptible to user input, error handling is a sine qua non.
 
no error handling is the stupidest type of arrogance.

error handling isn't for the code's sake - it's an acknowledgement of the frailty and humanity of the coder.
 
I learned Access db back in the mid nineties and have never used any error trapping other than my own input verification code.
I've written dbs for the local university which turned into full estates applications used by many people from reception staff through to top managers without a hitch.
There were initial snags when the IT department moved the back-end to a larger server but that was quickly resolved by them, not my code.
 
So Far:
What I've mostly heard here is "we do it this way".
I specifically avoid Error Code, because I want them to find the problem.
I want them to shut down, to break, to stop functioning.

Then they run for decades, actually doing what they're supposed to do. And, yes there are time when the only solution is to handle an Error, but in our systems it is the exception, not the rule.
 
In the interest of clarity, I should have explicitly excluded Data Validation, of any kind, in my original statement.
To repeat, I it is in extremely rare situation where i would use "Resume on Error" maybe less than a dozen times over the last 20 years. And only, when no other method would work.

It's the same with Referential Integrity, I only remember once using it as a tool. That was because I was just too darned easy to do.
 
@MajP
I know you try. But for God's sake don't tell me you can. You are one of the best programmers I've ever seen (I'm young and only 3 years into PC world). but you can't be perfect.

The following errors are from the most expensive CAD application (Solidworks). Even programmers on that range can not be bullet proof.
Google Solid works funny errors for more:


View attachment 94532


View attachment 94533


--------------------------------


View attachment 94534
Exactly how do you think Error Checking would have prevented that?
 
Now I'll admit to a small degree of surprise. Error handling, referential integrity, and data validation are just procedures in your "toolkit." There are indeed times when you would not use certain things. However, these are such basic "tools" that I can't imagine not having them in my kit and using them when they are appropriate.
 
It's the same with Referential Integrity, I only remember once using it as a tool.
Do you also not wear a seatbelt because you're the best driver in the world?

You remind me of a rookie programmer who worked for my company. She was known far and wide as "Julie No Test". She was soooooooo good that if her code compiled, no testing was required. It would just work.

Flouting good practice methods because you are sooooooooo good that you don't need them does not speak well for you.
 
Do you also not wear a seatbelt because you're the best driver in the world?

You remind me of a rookie programmer who worked for my company. She was known far and wide as "Julie No Test". She was soooooooo good that if her code compiled, no testing was required. It would just work.

Flouting good practice methods because you are sooooooooo good that you don't need them does not speak well for you.
And did her code work without errors? You didn't say.
 
And did her code work without errors? You didn't say.
Even a broken clock is right twice each day. Sometimes, but she didn't do any error checking so bad things happened that we didn't know about until integration testing. That's when other programmers found the errors that were ignored.
 
I'm very late to this thread and many of my own thoughts have already been expressed.

However, I'm incredulous that any serious developer would treat it as a matter of pride that they do not use error handling in ACCDB or ACCDE files distributed to clients.

Of course, like any experienced developer, I test my code thoroughly before it is released. I deliberately look for problems so these can be solved before end users are involved. I do this both to ensure UX is as good as I can make it and to protect my own reputation as a developer.

However, I am well aware that no developer is perfect and things may slip through...in extreme cases with errors not being noticed for several years.

As already mentioned, not all possible modes of use can ever be tested...some end users have ways of doing things that can never reasonably be foreseen...and which may lead to very obscure errors.

I ask my clients to report all errors...no matter how trivial...but inevitably that doesn't always happen.
As a result, after over a decade of continuous use by several thousand users of my main schools app I set up detailed error logging with automated emails sent to me (with the clients' permission) as the primary developer listing full details of what/who/when/where/why/how etc.

In the first month, I was inundated with automated emails which allowed me to fix issues going back a long time but that had NEVER been brought to my attention, nor had shown up in any pre-release testing. The majority of those errors pre-dated my own involvement with the application...though not all. Within 3 months, the errors had all been fixed and the emails stopped...to my relief.

That particular app was supplied with a highly locked down ACCDB FE. If it had been an ACCDE, the app would simply have crashed when those errors occurred.

Moving on from unintended programming errors, there are errors that are built in to Access that need to be handled.
There are several examples of this type. For example:
1. A report with no data is loaded from a form. Using the Report_NoData event the report is closed automatically.
However that triggers error 2501 in the calling form .
2. Code is used to select a file or folder using file system object (FSO). If the user cancels, error 5 occurs

In both cases, that error needs to be handled. If not, an ACCDE FE will crash.

So - do enlighten me, how would those be managed without error handling?
 
but you can't be perfect.

MajP will tell you different! On his 1st day here he arrogantly proclaimed how clever s/he is, and how thick the rest of us are... Only a "Thick" person would hold such a view.
 
I ask my clients to report all errors...no matter how trivial...but inevitably that doesn't always happen.

This is a pet peeve of mine, and I'm dealing with fellow employees. I've had a vehicle maintenance app running for a long time. I added functionality to sync new repair orders with an outside vendor. It threw an error if this didn't happen properly. My error handling threw up an error that included "notify Paul...". It started failing when the vendor changed something, but nobody told me. Their repair order was still being created and that's all they cared about. Maybe I should implement your email method. :rolleyes:
 
Exactly how do you think Error Checking would have prevented that?
You're asking me? I don't know. I'm not a programmer.
But when an application shows you an empty message box, or tells you "This table was made in Excel 2010 and excel 2010 can not open it" or some meaningless messages, apparently something has gone wrong and it hasn't been trapped. Otherwise I should have seen a logical message.
 
Last edited:
MajP will tell you different! On his 1st day here he arrogantly proclaimed how clever s/he is, and how thick the rest of us are... Only a "Thick" person would hold such a view
Wow now that's a bold statement. What gives? I would be very interested in any post that I hinted that I was perfect and that others on this forum are "Thick." I do not ever think I suggested something like that. I do think when It comes to Access I am pretty "clever", I am sure you do too. Clearly after 10s of thousands of posts and 100s of thousands of lines of Access code posted, I might know a thing or two. I have also said why that is. I have been on these forums answering threads for years. I have learned from others questions. Teaching is the best way to learn. I enjoy taking on the challenging problems.

I cannot find any of those suggesting I am perfect and others are not, but I can find ones where I express opposite views to that.
Only a "Thick" person would hold such a view.
Also not sure what you think my view is.

I stated that I do not shotgun my code with aimless error trapping blocks. I instead spend a lot of time trying to account for any possible errors. When I do include error handlers it is purposeful. I know the code has a potential vector where I cannot foresee the possibilities. I just think people think that error handlers are a get out of jail free card. Instead of doing the work and accounting for the error they just let the error be thrown. Even worse is when people use an error handler for program flow.
I would much rather see a code written with a deliberate approach to account for potential errors and no error handler, versus no attempt to account for potential errors and an error handler. I never mentioned anything about distributing ACCDR

Also as a "Staff Member" for AWF not sure why you feel the need to attack me. Not sure what I said on this thread that justified that response from you. If I said something 3 years ago and a few thousands post ago and you cannot get over it, then that might be your problem and you need to give it a rest. Just because I have disagreed with you at times and proven you wrong on several threads, does not really warrant that attack. Instead of getting all upset, if I disagree with you then prove me wrong. I will say I will act like a cornered cat, and one someone tells me I am wrong and I know I am not then expect me to react.
 

Users who are viewing this thread

Back
Top Bottom