• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How much do you say about defensive programming?

 
Marshal
Posts: 79179
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have been discussing defensive programming here. How much do you say about defensive programming in the book?
 
Author
Posts: 30
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my book, I mentioned defensive programming in light of Design by Contract (DbC).

Design by Contract (DbC)

The notion of contract relates to obligations and benefits. An obligation to one party (supplier) is a benefit to another party (client).

In programming, contract is translated to precondition and postcondition.

Precondition > Process > Postcondition

The following can be observed from DbC:
- the stronger the precondition, more work for the client
- the stronger the postcondition, more work for the supplier

The following assumptions can be made when error occurs,
- Error in runtime is an indication of a bug
- A precondition error is a bug in the client
- A postcondition error is a bug in the supplier

The benefits of DbC is that there is less programming involved – you get more, you check less. There is less redundancy and there is clear separation of responsibility. Both client and supplier knows exactly their boundaries. DbC also contributes to software reliability and testability. It also results to clear documentation and easy debugging.

As opposed to defensive programming, you always check for precondition, you always validate inputs anywhere they appear. You’re checking things blindly just in case. This style leads to a lot of redundancy and code bloat. Everyone is responsible yet no one accepts responsibility.

 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you.
 
reply
    Bookmark Topic Watch Topic
  • New Topic