No announcement yet.

Error Trapping Question

  • Filter
  • Time
  • Show
Clear All
new posts

  • Error Trapping Question

    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>
    Donnie Ewald
    [email protected]

  • #2
    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:

    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!


    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).]


    • #3
      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:
      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>
      Sebastian Groeneveld
      mailto:[email protected][email protected]</A>


      • #4
        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>
        Donnie Ewald
        [email protected]


        • #5
          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]
          Mike Luther
          [email protected]


          • #6

            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.


            There are no atheists in a fox hole or the morning of a math test.
            If my flag offends you, I'll help you pack.