>>This way you don't have to have other exits but the early exits (before you disturb the settings) and one final exit (where you restore the settings).
>
>That's just one way to do it. You may not always be able to exit before the settings have been changed.

Sure, I was talking about early exits - and my definition of "early" is "before we get to business", i.e. when we have a reason why a process cannot start.

>IMO the lOK scattered through the block of code makes it harder to follow the logic. I find things much easier to follow if they exit as soon as processing cannot continue.

Either way, spotting the place in a block of code where (in your case) it exits, or (in my case) sets lOK=.f. is the problem. Either way, you know the rest of the code to the end of procedure will not be executed. I think we're into preferences now. Having changed jobs a lot, I've learned that all of them work under one condition: consistency. If we have exits in the middle, it's OK if it's so everywhere. If we have deferred exits, also OK if it's so everywhere. Once you get in a mixed soup with such things, even neatly written code can be hard to read, because you'll actually have to read it :).

>But the point I was trying to make is we have more freedom to decide how to code things with these classes protecting us from ourselves.

I was using those, and they really do make things easier. They are one of those "set it and forget it" things. Though, when you step through code, you have to step through their .destroy() method as well. That's not much of a hassle, though.