Nate DeSimone wrote:
In general gotos are *REALLY* bad, there must be some better way than gotos to get this working, maybe it would be a good idea to put some work into PSEH so that it is suitable for this purpose and save yourself the trouble of doing it later.
There is nothing inherently wrong with goto, it's only bad when it makes the code less readable. When used carefully, like in this case, it creates code that is _more_ readable, not less, and that's clearly a good thing. Also as I said before, the problem is not a lack of SEH, as I believe that is now supported by gcc so we could use it, but rather the problem is that virtually none of the NTAPI uses SEH. In order for SEH to be beneficial, it's use has to be widespread.
Robert Köpferl wrote:
I can just ACK your post.
Not using goto is like a no-no. It was for the last 15y and will be another. (?) The schools teach it. But one should allways think about the "Trueth" wether it is ture or just "dontcare".
Using Exceptions and the resulting stack unwind etc. is not nice concerning performance. However it leads to more secure and elegant code. I for my part would rather insert some spare gotos. AND use auto variables. _______________________________________________
Just because schools teach it does not make it true. Half of what they teach in school is wrong. As I said above, there is nothing inherently bad about goto, it's just that it can easily be abused to create spaghetti code, and new programmers often do just that. When used carefully goto can be the lesser of two evils, as in this case. I think it is clear that the code using goto is much cleaner and more maintainable than the original code. If using goto improved the code, then it has got to be a good thing.
C++ exception handling is the ideal way to handle this kind of thing, but we're mostly using C and all the APIs are in C, so it is with C that we must make our peace. Also blanket statements like C++ exception handling adds too much overhead are very often quite wrong. Often C++ exceptions actually IMPROVE performance because they eliminate multiple return value checks, duplicate code, and so on in favor of paying a very small fee when entering and exiting non trivial functions. In the case where an exception is not thrown, which is to say, the vast majority of the time, the small overhead for pushing the exception handler onto the exception stack is more than made up for by the overhead saved from not having to constantly check a dozen different return parameters. In fact if you have say, a loop, which calls 3 functions each iteration and iterates 100 times, you are saving a ton of overhead by trading 300 return value checks for one exception handler push/pop.