On error goto....
-
Brady Kelly wrote:
Yes, I agree, but On Error Resume Next should be punished by stoning to death with golf balls.
True, but that should also apply to the try/catch/do-nothings.
codito ergo sum
Yes, even the try/catch/do-nothing-but-throw-again-and-break-the-call-stack.
-
use
goto,continueorbreak, you fail (break only allowed in switch statements.) use more then one exit in your function, you fail. and the prof was right... :)V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
Yes, even the try/catch/do-nothing-but-throw-again-and-break-the-call-stack.
I've seen way way too many of those in the short time that I've been working in C#. It's too late now, but it should have been the first thing taught to every VB developer making the transition. Even before they learned the syntax.
This blanket smells like ham
-
use
goto,continueorbreak, you fail (break only allowed in switch statements.) use more then one exit in your function, you fail. and the prof was right... :)V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview ArchiveI use continue all the time, and if you have a function that doesn't support multiple return statements easily then your function is probably too complicated. Though, back in the C days it was hard to keep functions simple enough. My arbitrary flow control dogma would be if you have more then 2 nested if, while, switch or for statements you fail.
This blanket smells like ham
-
I use continue all the time, and if you have a function that doesn't support multiple return statements easily then your function is probably too complicated. Though, back in the C days it was hard to keep functions simple enough. My arbitrary flow control dogma would be if you have more then 2 nested if, while, switch or for statements you fail.
This blanket smells like ham
Andy Brummer wrote:
if you have a function that doesn't support multiple return statements easily then your function is probably too complicated
On the contrary, bugfixing with your function only having one return is more easy than when it has, let's say, 5 return statements. There's nothing more ugly then having something like this
if(something == true){
return;
}tastes differ I guess :-)
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
Multiple exits can greatly improve readability when you have extensive error checking at the start of the routine. Judy
With extensive (more than 2 or 3 checks) I generally refactor all the error checking into
bool ValidateFunctionName(...).Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
-
With extensive (more than 2 or 3 checks) I generally refactor all the error checking into
bool ValidateFunctionName(...).Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
True, but that Validate function is still easiest to read if it has multiple
return falsestatements for each error check that fails and one finalreturn trueat the end if it passes all the tests. Regardless of where the error checking is, I always find it more readable to do it this way rather than massively nesting the multiple error checking to force the routine into only having a single exit point - the OP's original point. Judy