Printable View
I'm a calling a sub in a module from an on click event in my form. In the sub I doing some validationns. If it's not a valid entry, I dispaly a msgbox then exit the sub, but the program still goes through the rest of the code in my on click event. is there a way to stop this? If the entry is not valid I want to stop the event and then place the cursor in the textbox that needs to be adjusted.
Can you post sample of what your're talking about ?
Change your sub to a function and return a boolean value. Return False if your function that does the validating finds incorrect data. Then in your event code, you can then Exit Sub if you returned false.
thats what I was thinking too...the thing is that I have so many different validations that I'm going to have to set a differnt flag for each one to determine which txtbox didn't validate....looks like thats what I'm going to do...thanks
just a thought. It may be possible to put the whole thing into a new thread and kill the thread out right when you want out.
Exit Sub is essentially created for such cases (I have done a lot a lot of them this way ) :
Consider this example
This sub check if "str" isn't a vlaue of 1 to 3 then it shows msgbox and EXIT SUB (checkvalue) .
Just a thought !VB Code:
He means exit an entire stack. like he is in a sub 1 that calls sub 2. When he exzits sub 2, he doesnt want to go back to sub 1 which is what he is talking about
as I understood your explanation , it can be done the same way .Exit Sub can be typed in any sub , and it will stop the flow of next code.
Dunno if I'm getting it right !:rolleyes:VB Code:
I have my edits in the module where I'm calling the sub
in module:
VB Code:
in form:
VB Code:
No there is still more to his request. But he was basically answered with the need to use a function and check the return type before exiting.
I would NEVER recommend anyone use EXIT SUB in their code to force their subs to end, use proper error checking and let the function end gracefully at the END SUB.
even if you use the try, catch method your code is going to run till the end of the procedure even if an error is caught.
What is so wrong with exit sub? Now in .NET you can use return also to return or exit from a sub early.Quote:
Originally posted by shutty
I would NEVER recommend anyone use EXIT SUB in their code to force their subs to end, use proper error checking and let the function end gracefully at the END SUB.
I don't see anything un-graceful about Exit Sub, in fact I think shortening the sub to just what is needed is better.
Yes you can do this, but it is bad coding practice. It is far easier to debug code if you know the only way out of a function/sub is at it's end. There is nothing more infuriating than setting breakpoints in a function during debugging that are never reached because the function exited/return, early than you expected. You then have to trawl through the code to find all the exit points.Quote:
Originally posted by Edneeis
What is so wrong with exit sub? Now in .NET you can use return also to return or exit from a sub early.
I don't see anything un-graceful about Exit Sub, in fact I think shortening the sub to just what is needed is better.
I guess I'll chaulk this one up to opinion. I don't find it any more difficult to debug especially if you keep your methods small and the exit points are logical.
How said "using EXIT SUB is bad practice" ??;)
Well , Can you prove it ?
Why MS put that in use if it's so?
When we say bad coding habits , this implies number of things :situation and time . For example , we don't declare variables between fragments of code rather we declare them at the top of a method.
Exit Sub , can appear anywhere in the sub .It has many advantages one of them is to prevent error-handling code from running when no error has occurred immediately before the error-handling routine
[Examples were taken from MSDN Help ]
This is a VB6 example .
Note You must place an Exit Sub statement immediately before the error-handling block. Otherwise, Visual Basic runs the error-handling code when it reaches the end of the subroutine, causing unwanted or unexpected results.VB Code:
__________________________________
This example(VB.NET) uses the Exit statement to exit a For...Next loop, a Do...Loop, and a Sub procedure.
So Exit sub is the methodical way to end your sub in certain situationsVB Code:
Look at MSDN , and see how it's been used heavily .
I'm a fan of the Exit Sub method too, so I'm going to have to agree with the majority...thanks for all the input though
Lol. Thats got to be one of the funniest things I've ever read. So I suppose when you have a function that has multiple decisions you should only have one return? Bwahaha.Quote:
Originally posted by shutty
I would NEVER recommend anyone use EXIT SUB in their code to force their subs to end, use proper error checking and let the function end gracefully at the END SUB.
Although you may think so, code is a lot more readable when you have exit sub/return calls in the procedure/function as it reduces the overall amount of code. In fact I would much rather step through an entire procedure than get confused as to why there are so many if statements. If you ever do code maintanence you'll be grateful if someone is using Exit Sub calls to exit the procedure.Quote:
Originally posted by shutty
Yes you can do this, but it is bad coding practice. It is far easier to debug code if you know the only way out of a function/sub is at it's end. There is nothing more infuriating than setting breakpoints in a function during debugging that are never reached because the function exited/return, early than you expected. You then have to trawl through the code to find all the exit points.
When ppl understand me , aaah I feel better .:D
[QUOTE]Originally posted by marnitzg
Lol. Thats got to be one of the funniest things I've ever read. So I suppose when you have a function that has multiple decisions you should only have one return? Bwahaha.
yes, absolutely.
if a programmer submitted the above for review, I would personally shoot them. If you need to end a loop under a certain condition then put that condition in the loop definition. it's far easier to see how the loop will be exited if it's all checked for in one place.Code:-------------------------------------------------------------------------------Sub ExitStatementDemo()
Dim I, MyNum As Integer
Do ' Set up infinite loop.
For I = 1 To 1000 ' Loop 1000 times.
MyNum = Int(Rnd * 1000) ' Generate random numbers.
Select Case MyNum ' Evaluate random number.
Case 7: Exit For ' If 7, exit For...Next.
Case 29: Exit Do ' If 29, exit Do...Loop.
Case 54: Exit Sub ' If 54, exit Sub procedure.
End Select
Next I
Loop
End Sub
--------------------------------------------------------------------------------
Just because the language lets you do it doen't mean you should. Next you'll be telling me you still use Goto's!
Just realised that the code snippet comes from the MSDN help!
Just goes to show what I allows thought about Microsoft :D
That's almost as bad as some of their Wizard generated code!
I have to agree with shutty on this. Practical Standards for Microsoft Visual Basic.Net published by Microsoft Press states that you should give every procedure a SINGLE exit point (see chapter 2 Directive 2.2 Give every procedure a single exit point. page 23).
huh !Quote:
Originally posted by shutty
Just realised that the code snippet comes from the MSDN help!
Just goes to show what I allows thought about Microsoft :D
That's almost as bad as some of their Wizard generated code!
yah , from MS .You shutty , Remember MS give you orders to follow their rules code conventions(I like that:D) (actually they force you;) ) .You're trying to create a problem out of nothing . I have no idea why you are still debating in such determined issues .bull****
But looking at jaycee's reply microsoft even contradict themselves on this issue. In their coding standards they promote the one exit point method in their coding examples they demonstrate the other. Hardly reliable.
I am as you say only debating the issue as you yourself still are.Quote:
I have no idea why you are still debating in such determined issues
As Edneeis said "I guess I'll chaulk this one up to opinion". I do however have the ability to debate the issue without resorting to calling other peoples opinions bull****.
shutty wouldn't it just be easier to place an Exit Sub in your code then writing out a bunch of IF statements to test...
Completely agree with you! - what I'm debating here is not ease of coding but best practice.Quote:
Originally posted by EyeTalion
shutty wouldn't it just be easier to place an Exit Sub in your code then writing out a bunch of IF statements to test...
I'm used to working in project teams of 10+ people, when all procedures use the one exit point approach then it is far easier to debug. By only placing a single breakpoint at the end of the function I can then summise under what condition the procedure ended. Rather than spending time looking for all exit points.
At the end of the day 'best practice' is all about what your organisation feels is the best approach to produce quality and maintainable software. I have worked for a number of software houses, in different industries, that have had this as one of their coding standards. I'm not just refering to VB projects here but projects I have been involved in with C, C++ and Java as well.
I somewhat agree with Shutty.... its been something I've heard as the 'ideal' practice to exit a sub... from textbooks...
but I don't completely agree with it... every sub having one exit point usually involves extra processing and overhead because the machine has to step-thru that extra code and conditionals before it can return. Certain processes require speed and while checking for a few extra conditions might not seem superflous performance-wise, I would rather slap an Exit Sub or Return... and know the code runs as lean as it can.
In a language like C++ you might be best to do so because it can be a nightmare to debug, less so with Java, even less with .Net.
Additionally, you might end up introducing more logic errors by throwing too many conditionals in there.
As far as the Microsoft contradicting itself, well, you have a few thousand programmers there, and like us, they all have their different beliefs, so I suppose the variance in coding practices there is about as large as the Pacific Ocean.
You're contradicting yourself !Quote:
Originally posted by shutty
I would NEVER recommend anyone use EXIT SUB in their code to force their subs to end, use proper error checking and let the function end gracefully at the END SUB.
How so?Quote:
Originally posted by Pirate
You're contradicting yourself !
This could go on for weeks....:D
Actually I will end it now. Use Return now isntead ala C++!
it doesnt have to be a function to do a Return as a Sub is just a Function anyway that returns void
:D
That covers Exit Sub, but what about Exit Function.
LOL - Just kidding! :)
Ahh you see though, no one can say its bad practice. Because if return was bad practice, then it would be practice to use a function and Return a value! :p
See?
:D , yeah Exit Sub issues is over now. Wanna start Exit Function . lol . No way ! kiddin lol
Everyone has their different view points. In this case, it seems everyone disagrees with you :rolleyes:. I have worked for 3 firms so far in my short life and none of them have complained when I use exit sub/returnQuote:
Originally posted by shutty
At the end of the day 'best practice' is all about what your organisation feels is the best approach to produce quality and maintainable software. I have worked for a number of software houses, in different industries, that have had this as one of their coding standards. I'm not just refering to VB projects here but projects I have been involved in with C, C++ and Java as well.