As far as I can tell, since OnErrorResume was eliminated from PureBasic,
all the OnError statements force you to terminate the program. except
OnErrorGoto which could leave you with a "Hellish" stack problem.
Is there any way to safely continue your program, if you know that it would
be alright to ignore an error?
OnError Goto Hell(?)
-
IdeasVacuum
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: OnError Goto Hell(?)
The problem is, you might know it is OK to ignore an error, but you will never know every possible error, so continuing could make things a lot worst. However, if an error is captured and the Procedure for handling the situation runs, it could save essential data, do a clean-up, pop-up a message for the User (including the error to be reported back to you), and then auto-relaunch the app exe via RunProgram().
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: OnError Goto Hell(?)
Hi IdeasVacuum,
I understand the rational behind forcing a program close
on an error but I don't agree that it should be necessary,
in all cases.
Some errors are caused by bugs in the programming
language that you are using and others by the O/S.
In fact, in the case I am discussing, I had already done
what you suggested. Looped back and re-launched the video
that had aborted.
My problem is, I don't want the user to see "I/O error 145"
in a message box that they need to click. One type of
animated screen saver that I am using doesn't like to
be interrupted and generates this error. I need to catch
it and continue before it gets to the user.
No need to try to sell me on the virtues of error proofing.
I once coded a rather large job shop control system, that
ended up with about as much error proofing as regular code.
Ran it for over 5 years with no errors appearing. Of course,
that did make me wonder.
I understand the rational behind forcing a program close
on an error but I don't agree that it should be necessary,
in all cases.
Some errors are caused by bugs in the programming
language that you are using and others by the O/S.
In fact, in the case I am discussing, I had already done
what you suggested. Looped back and re-launched the video
that had aborted.
My problem is, I don't want the user to see "I/O error 145"
in a message box that they need to click. One type of
animated screen saver that I am using doesn't like to
be interrupted and generates this error. I need to catch
it and continue before it gets to the user.
No need to try to sell me on the virtues of error proofing.
I once coded a rather large job shop control system, that
ended up with about as much error proofing as regular code.
Ran it for over 5 years with no errors appearing. Of course,
that did make me wonder.
-
IdeasVacuum
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: OnError Goto Hell(?)
...just replace it with another that doesn't fail.One type of animated screen saver that I am using doesn't like to be interrupted and generates this error.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: OnError Goto Hell(?)
Don't think that I haven't considered that.
Unfortunately, it is , by far, the most realistic
one that I have, but then I only have two.
What bugs me is that I have solved this problem
before, of filtering the message queue. I just
can't find the code.
Unfortunately, it is , by far, the most realistic
one that I have, but then I only have two.
What bugs me is that I have solved this problem
before, of filtering the message queue. I just
can't find the code.