Jump to label

[Kid]

Hi

I've seen many driver source use goto error label in functions .

Is it a good way to write driver functions ? I seldom found goto label in
application
project source .

Thank you.

[Doron Holan [MSFT]]

it is all a matter of style. typically you see one of three options
1) alot of nested if()s which check for success
2) a flat strucure of if()s, on failure goto error;
3) a do { } while (FALSE) loop. on error, you see a break; this is the
same as #2

it really just dpeends on what you want to maintain...

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Kid" <K...@discussions.microsoft.com> wrote in message
news:771ACB4A-2D5C-4699...@microsoft.com...

[Ray Trent]

Doron Holan [MSFT] wrote:
> it is all a matter of style. typically you see one of three options
> 1) alot of nested if()s which check for success
> 2) a flat strucure of if()s, on failure goto error;
> 3) a do { } while (FALSE) loop. on error, you see a break; this is the
> same as #2

Or, in C++ (hehe), using the "resource allocation is initialization"
(RAII) paradigm to clean up from error conditions (or any other exit
from a block) automatically in a destructor. Kind of a pain to write in
the general case, but it does make maintaining the code a lot less
hazardous for junior programmers.

Lots of nested if's tend to make my head hurt, especially when it's time
to maintain the code. So to me this is one of the rare circumstances
where goto's actually make a lot of sense.

I don't much like the do while false trick because it leaves you stuck
in lots of situations like this:

do {
for(...) {
success = DoSomething();
if (!success) {
?????????
}
}
} while(FALSE);

It's especially pernicious when this happens accidentally because
another programmer came along and added the for loop.

Yes, you can get around that by having a error holding stack variable
that is checked after any nested loops, but ugh.
--
Ray

[Egidio [MSFT]]

Plus applications often use try/catch/finally to be 'more' object oriented.

Egi.

"Doron Holan [MSFT]" <dor...@online.microsoft.com> wrote in message
news:u0Ji6uJv...@TK2MSFTNGP03.phx.gbl...

[440...@email.com]

Indeed. Just the small step of using auto_ptr is a more beautiful and
safe way to clean up rather rather than goto spaghetti.

[Doron Holan [MSFT]]

note that would be the SEH versions of try/catch/finally not the c++
versions, at least for drivers...which really means __try and __finally
w/out the throw. also note that code in a __try block will likely not be
optimized b/c the compiler has a very hard time knowing what will raise an
exception or not

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Egidio [MSFT]" <egi...@online.microsoft.com> wrote in message
news:%23cwsG6O...@TK2MSFTNGP05.phx.gbl...

[440...@email.com]

> also note that code in a __try block will likely not be
> optimized b/c the compiler has a very hard time knowing
> what will raise an exception or not

The compiler will know exactly what, if any exception will be raised
if throw() is specified in the function prototype. But you can only
use the magical throw() if your driver is C++ rather than C.