simplifying code

  • Thread starter Thread starter Sophie
  • Start date Start date
S

Sophie

hi

When I study code examples from this forum, I've seen the experts use code
like...

If CurrentProject.AllReports(strDoc).IsLoaded Then
DoCmd.Close acReport, strDoc, acSaveNo
End If

Here's my question. What's wrong with just using the DoCmd line while
scrapping the If and End If lines? Doesn't this still close the report if it
is loaded (visible or not) while producing no error if the report isn't
loaded?

Thanks
Sophie
 
That's a fair question, Sophie. Ultimately this is a question of style, and
you will choose a style that suits you.

As you found, closing a report that is not open (even one that does not
exist) fails silently, so testing whether it is loaded before closing it is
unnecessary.

But as you work in any programming language, you realize that debugging is
much harder than writing code. Finding and fixing bugs, plus verifying that
the code works correctly in all cases and in all versions of Access is a
much harder job. In practice it's an impossible job to test every
combination of cases, not to mention future versions of Access.

Even harder than debugging is maintenance. I've been asked this morning to
change some commission routines I wrote years ago, because of a change in
business practice. Making the new changes to work correctly without messing
anything else up: actually, I'm not looking forward to it.

So, you develop a style that strives to eliminate every possible thing that
could go wrong in the first place (bugs), and every possible thing that
could go wrong in future (maintenance, version changes.) That mindset can
look overly pedantic when you read the code.

Using your simple example, we assume there is a prior line such as:
strDoc = "Report1"
Now imagine that that line is mistyped -- say:
strDoc = "Report 1"
The code you posted will catch the error, i.e. the:
CurrentProject.AllReports(strDoc).IsLoaded
will fail if there is no such report. If you don't catch the error at this
point, you may have a much more difficult bug to find. For example, you
might be checking that the report is closed so you can open it with a
different WhereCondition, or pass an OpenArgs. If the report is not closed
properly, you will be racking your brains trying to figure out why the
filter doesn't work, or the OpenArgs is not being passed, but the bug was
back above where the code didn't close it properly.

So, my personal style is to code in such as way that Access will *catch* the
error when it happens.

One day I'm going to write an article entitled, "Why I love error messages."
I really do do everything I can to get Access to generate an error message,
'coz it's easier to sort it out if I know about it immediately rather than
if the problem shows up later in some unrelated line of code.

HTH
 
Back
Top