## Re: [XP] Eliminate Exceptions (was: Writing simple software - A Challenge!)

Expand Messages
• ... The Do The Math notion of Simple Design relates to this notion. In set theory (and relational algebra for that matter), a selection operator selects all
Message 1 of 139 , Dec 1, 2002
On Sunday, December 1, 2002, at 2:51:31 PM, Kyle Cordes wrote:

> Thus, I code this way:

> If valid parameters are passed, and underlying infrastructure works, do
> the right thing. If a parameter is bad, throw a meaningful exception.
> If an underlying layer fails, propogate it's exception upward,
> preferabley without munging it along the way.

The "Do The Math" notion of Simple Design relates to this notion.

In set theory (and relational algebra for that matter), a selection
operator selects all those records for which the selection proposition
is true, and none for which it is false.

Thus, given any set (or relation) X,

X select x such that 1=1

returns all the records, while

X select x such that 1=0

returns none.

Consider now a set of records People, containing fields Name, Address,
and Phone. The result of this query:

People select p such that p.Height = 72inches

is therefore an empty set of people. Now it is possible to argue (and
Kyle apparently does) that this query is a mistake and should hurl.
However, consider now a collection Folks, of objects which are various
subtypes of People, some of whom know their Height, and some who do
not. What do we expect from

Folks select p such that p.Height = 72inches ?

I find that returning all the folks who know that their Height is 72
inches is certainly simplest, and quite often best. If someone wants
to know about the people who don't know their height, they can ask.

If the subject is "Simple Design", and I believe it is, my
recommendation is to lean strongly in the direction of eliminating
exceptions.

Mind you, that doesn't mean eliminate /all/ exceptions. I'd leave in
all the ones that make my users job discernibly easier. If I could
think of an example, I'd give it. ;->

Ron Jeffries
www.XProgramming.com
The rules are ways of thinking, not ways to avoid thinking.
• So said ericheikkila on 12/4/2002 -------------------- ... Often, i means something. Say what you mean; mean what you say. :) J. B. Rainsberger,
Message 139 of 139 , Dec 7, 2002
So said ericheikkila on 12/4/2002 --------------------

>Single letter variables drive me nuts. ;)
>I use 'index' instead of 'i' (or loop, or maybe count, depending on
>the context).
>As far as abbreviations go...if the entire team agrees, fine.
>If someone on the team doesn't know that itr is the same as iterator,
>just change it to iterator.
>
>Usually, I'll not abbrev ;)

Often, "i" means something. Say what you mean; mean what you say. :)

J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603
All correspondence (c) 2002 Diaspar Software Services.
If you want to use it, just ask; don't steal.
Your message has been successfully submitted and would be delivered to recipients shortly.