Error Checking

[Sun_Force]

Just for being clear for the third image above :
Solidworks has no Address Bar at all.

 

[The_Doc_Man]

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.

 

[Isaac]

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.

 

[Dave E]

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.

 

[Thales750]

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.

 

[Thales750]

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.

This is my favorite line in the whole thread.

 

[Thales750]

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.

 

[Thales750]

@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?

 

[The_Doc_Man]

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.

 

[Dave E]

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.

 

[NauticalGent]

You are one of the best programmers I've ever seen

 

[isladogs]

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?

 

[Uncle Gizmo]

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.

 

[pbaldy]

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.

 

[Sun_Force]

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.

 

[MajP]

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.

Populate form from date control

Hi there, guys. I have a form with several fields from a table. One of them is the date. I'd like to populate this form by clicking in the date control and picking a date from the calendar picker. If the record exists, the form is filled with the data and the operator is able to update the...

www.access-programmers.co.uk

64-bit replacement for Lebans rich-text control (rtf2)?

I've been using the Lebans RTF2 ActiveX control to add rich-text editing capability to legacy 32-bit Access applications. I'm now migrating those apps to 64-bit Access. The built-in rich-text capability in Access is very limited and uses HTML encoding rather than RTF. Does anyone know of a...

www.access-programmers.co.uk

Solved - Format based Query

Need some assistance with writing a query and honestly and I'm not even sure how to put this into words. I want the query to find records where the field isn't in a specific format. The field in question is for the location in the warehouse and has a specific alphanumeric format with an optional...

www.access-programmers.co.uk

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.

 

[Sun_Force]

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.

Again I'm young and most of members here have more experience in life than me.
But with my limited experience, when I see someone brags about his skills, It gives me the idea he's not that good.
Not long ago, I read somewhere The more I learn, the less I know.
And I believe in it. The more someone improves in a subject, the more he realizes how deep that subject is and how less he knows.
Most of our professors in collage who talk over and over how good they are, simply are not that good.

In case of @MajP, it's a surprise if he had ever said something like that. I had a different view of him.

The more I learn, the more I realize how much I don't know
Albert Einstein

 

[MajP]

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.

Those errors appeared to be trapped, they are just not being trapped well. The error handler did not make a proper string for the message. If not you would not get a nicely formatted msgbox, it would crash or send you to the vbe if uncompiled.

In case of @MajP, it's a surprise if he had ever said something like that.

I know. Me too,

 

[The_Doc_Man]

MajP, while you do have a bit of an attitude sometimes, I don't believe that statement about "you claiming to write perfect code" is accurate. You will admit when you are wrong. OK, doesn't happen often - but you have been corrected a few times and admitted the error. Don't go looking for examples, though. Needle in a haystack.

But you've got a pretty good batting average. If you could just control that "cornered cat" attitude a bit more, you'd be pretty damned good.

 

[Dave E]

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?

I'm not sure I avoided error handling with a sense of pride. But I did take pride in the code I used to prevent errors and the resultant lack of errors reported by the users.
I prefer my own method of - for every step that requires interaction with a user or any transfer of data, internally or externally, check that it will work faultlessly.