Author |
Topic: Re: Help with Multi-user application (Read 1398 times) |
|
Richard Russell
Administrator
member is offline
 
Posts: 1348
|
 |
Re: Help with Multi-user application
« Reply #15 on: Sep 11th, 2016, 01:08am » |
|
on Sep 8th, 2016, 09:01am, roxyryan wrote:| I cannot break the program with the code below, it really works. |
|
I've only just noticed this:
Code: try
file.mode$ = "OUT"
gosub [openorders] ' open in read/write mode
catch
call delaysub, 100
gosub [openorders]
goto [set.orders.lock.repeat]
end try
I need hardly say that if the GOTO here is ever taken the program will almost certainly suffer a slow and painful death. It takes some bravado to jump out of a Structured Exception Handling clause with a GOTO - the antithesis of structured programming!!
Richard.
|
|
 Logged
|
|
|
|
roxyryan
New Member
member is offline
Posts: 4
|
|
Re: Help with Multi-user application
« Reply #16 on: Sep 11th, 2016, 12:05pm » |
|
Richard
Thank you for the kind words, but I think I told you previously that I had displays in my testing to prove which path the program followed. The program most certainly goes through this "goto" statement, and it works, every time. As I said previously, there are no doubt prettier statements to achieve the same, but this works.
Dermot
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Help with Multi-user application
« Reply #17 on: Sep 11th, 2016, 1:06pm » |
|
on Sep 11th, 2016, 12:05pm, roxyryan wrote:| The program most certainly goes through this "goto" statement, and it works, every time. |
|
Well, it rather depends on how you define "works". It is certainly the case that executing a TRY statement, but not executing the matching END TRY statement, will leave LBB in an unstable state. For example, if a subsequent error were to occur (for any reason) it would not be reported, and LBB would most probably crash. So at the very least debugging the program would be made much more difficult because even a trivial typo could result in an unexplained non-obvious failure.
It's a bit like jumping out of a loop (like a FOR loop or a WHILE loop) with a GOTO. That may appear to 'work', and indeed the program may keep running apparently correctly for hours or more, but eventually it will crash out for no obvious reason. In those cases there is an 'official' way to exit the loop prematurely, but there's no legitimate way of terminating a TRY clause other than executing the END TRY.
It's the very fact that the incautious use of GOTO is so prone to creating a 'fragile' program that many people (including me) will say it should ideally never be used at all. It's a subject that creates a lot of heated argument, and some people vociferously defend the use of GOTO, but even its most ardent supporters have to admit that it must be used with extreme care.
It's a basic tenet of Software Engineering that you cannot ascertain whether a program works or not by testing alone. Testing is valuable, but in most cases it cannot hope to exercise every possible path through a program, nor confirm that a program will remain stable even if left running for a very long time. 'Following the rules' is just as important as testing for ensuring that a program is reliable and resilient.
Richard.
|
|
|
|
|
