info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

frank.schoenheit


          Type: info
         Title: ENSURE_OR_CONTINUE/BREAK
     Posted by: [hidden email]
      Affected: -
         TaskId: i111236
<http://www.openoffice.org/issues/show_bug.cgi?id=111236>
Effective from: CWS slidecopy
           CWS:
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/slidecopy>
    CWS status: new


*Summary*
--------
tools/diagnose_ex.h:
+ ENSURE_OR_CONTINUE
+ ENSURE_OR_BREAK

*Description*
-------------
Complementing the existing ENSURE_OR_RETURN(_*) macros in
tools/diagnose_ex.h, which check a condition, and assert/return in
case of failure, ENSURE_OR_CONTINUE/BREAK have been added to the same
include file, which, guess, do a "continue" or "break" when the given
condition is not met (after asserting it).


Send feedback to [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

stephan.bergmann
On Apr 29, 2010, at 10:38 AM, [hidden email] wrote:

>
>
>          Type: info
>         Title: ENSURE_OR_CONTINUE/BREAK
>     Posted by: [hidden email]
>      Affected: -
>         TaskId: i111236
> <http://www.openoffice.org/issues/show_bug.cgi?id=111236>
> Effective from: CWS slidecopy
>           CWS:
> <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/slidecopy>
>    CWS status: new
>
>
> *Summary*
> --------
> tools/diagnose_ex.h:
> + ENSURE_OR_CONTINUE
> + ENSURE_OR_BREAK
>
> *Description*
> -------------
> Complementing the existing ENSURE_OR_RETURN(_*) macros in
> tools/diagnose_ex.h, which check a condition, and assert/return in
> case of failure, ENSURE_OR_CONTINUE/BREAK have been added to the same
> include file, which, guess, do a "continue" or "break" when the given
> condition is not met (after asserting it).

Defensive programming, eh?  Please don't.  (Look up the arguments against it in Bertrand Meyer's OO tome, for example.  "Defensive programming appears [...] to cover up for the lack of a systematic approach by blindly putting in as many checks as possible, furthering the problem of reliability rather than addressing it seriously.")

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

frank.schoenheit
Hi Stephan,

> Defensive programming, eh?  Please don't.  (Look up the arguments
> against it in Bertrand Meyer's OO tome, for example.  "Defensive
> programming appears [...] to cover up for the lack of a systematic
> approach by blindly putting in as many checks as possible, furthering
> the problem of reliability rather than addressing it seriously.")

Having seen a lot of nasty bugs and crashes which would have been
prevented by some more defensive programming, I continue to think that
defensiveness has its justification sometimes. (As always, using your
brain is a good idea, admittedly.)

But we both know that we won't reach an agreement on this topic ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Impress               http://graphics.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

stephan.bergmann
On 04/30/10 09:24, Frank Schoenheit, Sun Microsystems Germany wrote:

>> Defensive programming, eh?  Please don't.  (Look up the arguments
>> against it in Bertrand Meyer's OO tome, for example.  "Defensive
>> programming appears [...] to cover up for the lack of a systematic
>> approach by blindly putting in as many checks as possible, furthering
>> the problem of reliability rather than addressing it seriously.")
>
> Having seen a lot of nasty bugs and crashes which would have been
> prevented by some more defensive programming, I continue to think that
> defensiveness has its justification sometimes. (As always, using your
> brain is a good idea, admittedly.)

Working around errors in the program logic, by continuing in specific
ways (continue, break, ...) from a point where it is detected that such
an error manifested itself (assert) may sometimes "happen to work," but
in the end only masks the latent errors and makes the code unnecessarily
complex.

("Defensive programming" probably has various connotations.  Note that I
am not arguing against a programming style that properly takes care of
all the "unusual" states a program can legitimately get into.  For me,
that's not "defensive" programming but just plain normal programming.)

If you use those macros not to assert logic errors, but rather to flag
"unusual program states," I would prefer if you used something more
appropriate than OSL_ENSURE/OSL_ASSERT for that (say, OSL_TRACE),
especially in new code.  Remember that
<http://qa.openoffice.org/issues/show_bug.cgi?id=109142> "Let assertions
abort" will at one point force use to check all uses of OSL_ASSERT etc.
to sort out those that assert logic errors vs. those that merely flag
"unusual program states."

Apart from that, macros that hide control flow are IMO nasty.  Is the
savings gained by

   ENUSRE_OR_CONTINUE(...)

vs.

   OSL_ENSURE(...);
   continue;

really worth the trouble?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

christian.lippka
In reply to this post by stephan.bergmann
Am 29.04.2010 21:28, schrieb Stephan Bergmann:

> On Apr 29, 2010, at 10:38 AM, [hidden email] wrote:
>>
>>
>>           Type: info
>>          Title: ENSURE_OR_CONTINUE/BREAK
>>      Posted by: [hidden email]
>>       Affected: -
>>          TaskId: i111236
>> <http://www.openoffice.org/issues/show_bug.cgi?id=111236>
>> Effective from: CWS slidecopy
>>            CWS:
>> <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/slidecopy>
>>     CWS status: new
>>
>>
>> *Summary*
>> --------
>> tools/diagnose_ex.h:
>> + ENSURE_OR_CONTINUE
>> + ENSURE_OR_BREAK
>>
>> *Description*
>> -------------
>> Complementing the existing ENSURE_OR_RETURN(_*) macros in
>> tools/diagnose_ex.h, which check a condition, and assert/return in
>> case of failure, ENSURE_OR_CONTINUE/BREAK have been added to the same
>> include file, which, guess, do a "continue" or "break" when the given
>> condition is not met (after asserting it).
>
> Defensive programming, eh?  Please don't.  (Look up the arguments against it in Bertrand Meyer's OO tome, for example.  "Defensive programming appears [...] to cover up for the lack of a systematic approach by blindly putting in as many checks as possible, furthering the problem of reliability rather than addressing it seriously.")
Defensive programming? Please DO! I have yet to find a customer
reported problem that was caused by defensive programming. On the
other side I know (not guess, I know, we have numbers) how many crashes
we already fixed by Defensive programming.

Christian.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

stephan.bergmann
On 05/03/10 10:13, Christian Lippka wrote:
>> Defensive programming, eh?  Please don't.  (Look up the arguments
>> against it in Bertrand Meyer's OO tome, for example.  "Defensive
>> programming appears [...] to cover up for the lack of a systematic
>> approach by blindly putting in as many checks as possible, furthering
>> the problem of reliability rather than addressing it seriously.")
> Defensive programming? Please DO! I have yet to find a customer
> reported problem that was caused by defensive programming. On the
> other side I know (not guess, I know, we have numbers) how many crashes
> we already fixed by Defensive programming.

As I already wrote in another mail in this thread, "defensive
programming" was probably a bad term, as different people probably
understand it to mean different things.  To avoid talking past each
other here, can you provide an example of how what you call defensive
programming has fixed a crash?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]