Error Trapping Question

[Don Ewald]

Greetings All!

I'm trying to clean up my work area after my program runs and I'm having a slight problem with removing extraneous directories. I have the line:

RmDir "Unknowns"

...when this line executes and there are files within the directory I receive an error. Is there an easy way to bypass this error or to check for the existence of files within the directory? I'm cleaning up several directories and some should have files and some won't. I just don't want to unduly alarm the user when an error message pops up.


------------------
Don Ewald
mailto:[email protected][email protected]</A>

[Clay Clear]

You will get a runtime error if you try to delete ("rmdir") a
directory that has files in it, subdirectories in it, or if a
file in the directory is in use. You have to make sure that
none of the above exist before attempting to delete it.

You could have your program test for existing files\subs by:

DIM NDir AS STRING
NDir = DIR$("c:\Unknowns", 22)

IF NDir <> "" THEN
(put code to delete the stuff or take whatever action)
END IF
RMDIR "c:\Unknowns" (if you took any required corrective actions)

Replace "c:\Unknowns" with whatever drive:<path> is appropriate
for the directory in question.

As far as determining if a file in the directory is in use, I
don't know how to do that if a different process is using the
file. If it's the same program, then you should be able to do
that by examining your code.

Hope this helps!

Regards,

------------------
Clay C. Clear

mailto:[email protected][email protected]</A>

Clay Clear's Software

[This message has been edited by Clay Clear (edited September 03, 2001).]

[Sebastian Groeneveld]

If you really want to make sure you won't get a runtime error with these kind of
file/directory operations, you can trap the errors like this:

ON ERROR RESUME NEXT
RMDIR Directory$
ErrorCode% = ERRTEST
IF ErrorCode% THEN
    'Perform actions when command failed (depending on ErrorCode%)
END IF
ON ERROR GOTO 0 'or whatever you were using before...

The method Clay presented is very nice for checking whether a directory is
empty or not... but I'm sure there are many other situations that can cause
this RMDIR command to fail (marked as readonly, locked by Windows)...
Of course many of these situations can be left out if you just created the
directory yourself... but take them into account in the general case

------------------
Sebastian Groeneveld
mailto:[email protected][email protected]</A>

[Don Ewald]

Greetings Again!

I took Clay's advice first and tested this code:

MkDir "Unknowns"

IF Dir$("Unknowns", 22) = "" THEN
  RmDir "Unknowns"
END IF

...and things worked well. Unfortunately, when I dropped the code snippet into my program it didn't work. I'm assuming that it needs the full path line; but, I'm too lazy to add that right now.

I then evaluated the snippet from Sebastian and changed it slightly to my purpose and it works well. Thanks to both for the thoughts!


------------------
Don Ewald
mailto:[email protected][email protected]</A>

[Mike Luther]

In my personal venture into error trapping, I've found that the
use of RESUME NEXT has many, many pitfalls as your source gets
longer and longer. There are many cases where you not only
want to trap the error, but on the basis of what kind of error
it was, you may want to do several different things.

That almost always brings up to where you really want to resume,
and not just RESUME NEXT. In reality, as Lance or Tom once posted
here, I think, there are really only a couple of kinds of errors
from which you can really gracefully recover in most practical
programs. Thus the most practical thing to do is begin the long
slow process of figuring out which lines can really offer you a
graceful departure if things blow up.

Since error trapping proceeds on the basis of back to the last
formal numeric line number, the focus of all this is simple. You
assign line numbers to the places where bumps can realistically
take place.

Based on what error you find if it happens, you then make a choice
of exactly what you wish the program to do. Then you create a
specific RESUME to that target, not to NEXT.

Unless I'm operating under a target of ignorance, RESUME NEXT has
one other pitfall. It adds significant operational size to your
program. That's, I think, because to really RESUME NEXT, the final
product of the executioneer has to know every chopping line at which
to direct the ax when the time comes to X or cut bait!

As well, since Lance was so very kind to educate me on how to help
keep track of errors way off in nested SUBS etc., the use of
EXIT FAR sure stabliized my debugging life with this product. It
also sure helped to teach the IDE and PBD better manners, in my
humbled experience, about not coming all to pieces in corruption
errors in very big source code debugging.

Your mileage may vary, as may the octane of what you're using
that keeps you up late at night trying to determine where
the next bump in the road went...




------------------
Mike Luther
[email protected]

[Mel Bishop]

Don:

You might want to check to see if there are nested sub-directories
and/or hidden/system files in the sub-dir you want to delete.

Cheers
Mel


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