No announcement yet.

Error Trapping Question

  • Filter
  • Time
  • Show
Clear All
new posts

  • Mel Bishop

    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.



    Leave a comment:

  • 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]

    Leave a comment:

  • 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>

    Leave a comment:

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

    Leave a comment:

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

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

    Leave a comment:

  • Don Ewald
    started a topic Error Trapping Question

    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>