|
A try/catch/throw will still be more complex to write than what I have shown using the goto statement. The t/c/t approach would also require me to duplicate the 'abort on error' code.
David Wulff
dwulff@battleaxe-software.co.uk
|
|
|
|
|
The complexity level would actually be the same (at least in my opinion). Simply place a try statement at the top of the function, close it with a catch containing the "ExitWithError:" code at the same place you put that code. Then replace your "goto ExitWithError;" lines with "throw xxx" statements. This would not require duplicating the "abort on error" code.
The try/catch alternative can actually improve things, too. If you need to pass information to the error handling code, you can just throw the information. With the goto statement, you'd have to manually create variables, set them before calling goto, and then check them in the error handling routine.
Anyway, goto isn't bad. I just think there are better ways, and that it is normally worth the effort to use the better way than the quick and easy way -- especially after you make those better ways into habits.
John
|
|
|
|
|
|
I agree totally, I just didn't feel confident to say so.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
A good time for use of goto's is a top down parser implementation. My instructor at school called this 'blood sweat and tears' parsing. It is not that it is pretty or anything, it just can reduce the amount of code you gotta write, doesn't use any recursion, and is not that hard to make readable.
|
|
|
|
|
Have just run search for gotos in .CPP files in the MFC/SRC directory. Found 99 instances
|
|
|
|
|
Only because Microsoft uses goto's, it doesn't make goto's any better, or an excuse for using them.
Microsoft's programmers are only human, not programming-gods.
maXallion
"Is there any Tea on this Spaceship?" - Arthur Dent
Maxallion's World
|
|
|
|