• Please review our updated Terms and Rules here

Use ERR in deleting files - QuickBASIC 7.1

linuxlove

Veteran Member
Joined
Jan 11, 2009
Messages
1,018
Location
Auburn, AL
So I'm playing around in QB some and I've been messing with ERR. What I want to do is if a file doesn't exist, use ERR to handle errors instead of crashing the whole program. Here is the current code I have:

Code:
begindel: 'can be used to tell the code to restart using "GOSUB begindel"
input "File to delete: ", whatfile$
kill whatfile$
select case err
 case 53
  print "Flie not found"
  end
end select
However, when I try this, instead of seeing "File not found", I get "File not found" in QuickBASIC's screen. What am I doing wrong?
 
I thought you declare it with on error goto end and when the program hits an error it will then go to your error command (where you can do a resume or end the program). Are you sure it's just on the QB screen and not in your output window? I think your code is better than mine though as far as handling the error type in a case by case basis.
 
What it currently does:

File to delete: lol.wut (file doesn't exist)
QB main screen (the one where you see all your code) said:
File not found <OK> <Help>

Are you saying that at the top of my code I should have "on error goto end"? Can "end" be substituted for a label, like "errorhandle"?
 
It's been a while but yes you use a label and it will jump to that when it realizes an error occurs. Years back in some early programing experiments it took me a while to figure out how to use that command but I had the same issue with trying to open com ports and get the program to continue if the com port wasn't enabled or connected to anything. Otherwise as I think you're finding the application itself will intercept the error and stop running your code.

Not quite as helpful of a link as I'd like to post but it's entertaining that Microsoft has QB help on it's website
 
What I did:
Code:
begindel: 'can be used to tell the code to restart using "GOSUB begindel"
on error goto 500
input "File to delete: ", whatfile$
kill whatfile$

500 rem
select case err
 case 53
  print "Flie not found"
  end
end select

And it works! Thanks barythrin.

Now to go ask more questions ._.
 
You can also try something like:
Code:
begindel: 'can be used to tell the code to restart using "GOSUB begindel"
on error resume next
input "File to delete: ", whatfile$
kill whatfile$
select case err
 case 53
  print "Flie not found"
  end
end select
 
For text labels, you must use "TextLabel:". For numbers I just use "1 REM"; 1 is the number and REM just tells it to ignore that line and move on. Using "GOSUB" like this:

Code:
1 REM
print "Hello World!"
GOSUB 1

Code:
ProgBegin:
print "Hello World!"
gosub ProgBegin

Both work the same way, they loop "Hello World!" onscreen.
 
For text labels, you must use "TextLabel:". For numbers I just use "1 REM"; 1 is the number and REM just tells it to ignore that line and move on. Using "GOSUB" like this:

Code:
1 REM
print "Hello World!"
GOSUB 1

Code:
ProgBegin:
print "Hello World!"
gosub ProgBegin

Both work the same way, they loop "Hello World!" onscreen.
GOSUB??? I woulda thought you'd run out of memory; does it really loop forever?
Why GOSUB?
I think you really need to do a little reading...
 
I despise the ON ERROR statement after having debugged a couple of programs where the author forgot to reset the error target and an exception was thrown later in the code resulting in a "How did it get there?" situation. After the occasion for an error to be thrown has passed, always follow with another ON ERROR. ON ERROR GOTO 0, I believe, resets the default error handler.

Never be non selective with ON ERROR target code. Check the ERR variable for the exception that you're expecting, and have some mechanism to deal with everything else. Otherwise, you can get into a loop that will not resolve itself.

Just some friendly hints about a really badly thought-out BASIC construct. :)
 
Regarding MikeS's statement, I'd have to test it to know if it really loops and does non-ending calls or if it actually linearly runs the commands. In dos for example a batch file which calls itself will actually run each command at a time (it doesn't load it in a buffer which is weird which you'll find out if you do anything to lose access to the .bat during your commands) but it actually ends itself and calls itself again. In linux when I ignorantly did a script to do netstat and call the script again the system ran out of memory and crashed.

Interesting differences so I don't know being written by Microsoft if a gosub really would me a memory leak or not although unless it's really a sub then you could just goto ProgBegin: which may be what he meant.
 
Infinitely nested GOSUBs will result, not in a memory leak, but a stack overflow. The program will terminate and you'll get all your memory back again (unlike a memory leak, where memory simply disappears somewhere into the Pacific Thrall, never to be seen again). A GOSUB records the return address every time it's invoked, so eventually you run out of space to store them.

Anent DOS batch files. A batch file that CALLs itself (i.e. uses the CALL statement) will run out of memory pretty quickly. COMMAND.COM needs to keep a record of the name of the batch file and the location within it from which the CALL was executed. If you simply invoke another batch file by using its name without a CALL, it's equivalent to a GOTO statement--you go, never to return. So no additional memory is required.
 
Back
Top