RE: Changing error message

Hi Cédrick,

Ok first remember that this is a HACK and is not intended for regular use.
So before I give you the hack I want to tell you a little about proper
programming.

1) Methods should be short.  Only a few lines long.
2) You usually don't need a lot of parameters in methods.  If you have too
many parameters then you are probably missing an object.
3) Methods should care about self.  If you don?t see self in your instance
method then you are probably programming on the wrong object.  Pay attention
to where you put your code.  If self is really not needed then you should
probably be writing your code on the class side.
4) Avoid hard coded values, use references when possible.

Ok so now here is the hack.  Say you have been writing code for months and
you finally have everything you want just so.  Someone then says, hey can
you add this or that, and you realize that there is data missing to get it
done.  I started on Object A with the right info but by the time I got to
Object G hundreds of methods away it has no idea about Object A or what data
was used to create it.  What am I going to do?  The answer is to use
exception handling as a way to pass a parameter. (I told you it was a hack).

How about an example: 

CashRegister >> saleItem: anItem price: aPrice taxRate: aTaxRate
        "adjust inventory, record taxes and update receipt"
        self inventory removeItem: anItem.
        self recordTax: aPrice taxRate: aTaxRate.
        self receipt addItem: anItem.

CashRegister >> recordTax: aPrice taxRate: aTaxRate
        "record taxes to be paid later"
        self taxPeriod recordTax: aPrice taxRate: aTaxRate

CashRegister >> taxPeriod
        "get the current Tax period"
        ^Tax getPeriod: Date today.

This was great until someone said to you, we need to go back and re run all
of our receipts to generate a tax report because we were just audited and we
didn't charge enough tax because our system had the wrong tax rate.  You go
and look at the code and say to yourself, "Self the code doesn't even
mention date anywhere accept using the current tax period, Do I need to
rewrite all the code to get this to work?"  

I'm sure you could come up with better examples of this; I'm just making
this up.  Also be aware there are better ways to solve this problem, but
here is one.  Assume that this is difficult for some reason like the dates
the items were sold can only come from the inventory.  Since you will be
processing your new tax report from each item the dates are all jumbled up. 

If you wrap your code in an exception handler

        Inventory allItems do: [:anItem |
                soldOn := anItem saleDate.
                aPrice := anItem salePrice.
                aTaxRate := anItem correctTaxRateForDate: soldOn.
                [myRegister saleItem: anItem price: aPrice taxRate: aTaxRate
                ] on: GetSaleDateError 
                        do: [:ex | ex resume: soldOn].
        
Now in your CashRegister >> taxPeriod code you write:

CashRegister >> taxPeriod
        "get the current Tax period"
        ^Tax getPeriod: GetSaleDateError raise.

In order to not break your regular code you will need to wrap the normal
call to saleItem:price:taxRate: with: 

on: GetSaleDateError do: [:ex | ex resume: Date today].

Like I said it is a hack, and very hard to read and bad form, but if your
parameters are very far away it can be a life saver.  And again all of this
could have been prevented by using a better design and anticipating problems
with things like hard coded dates.

Notice that the do: block is in the context of the method when it was
executed which means you have access in that block to anything within that
method.  

Hope that helps, (Don't tell anyone I mentioned this !^)

Ron Teitelbaum




________________________________________
From: cdrick [mailto:cdrick65@xxxxxxxxx] 
Sent: Monday, August 21, 2006 11:09 AM
To: Ron@xxxxxxxxxxxx; A friendly place to get answers to even the most basic
questions about Squeak.
Subject: Re: [Newbies] Changing error message

really interesting...

If I remember well I've seen Stephan saying that it's not always good
practises tu use exception handling ...

what are the limits ? when to use or when not to use ...

It seems appropriate to me when there is a user entry to control it and
avoid human input error (WAValidationDecoration in seaside uses
WAValidationNotification for the Store example for instance) therwise, I
don't really see...





So now you can see that if the user does something wrong we handle the 
error.  Notice that the errors are raised up the stack in depositAmount: but
the handler is executed in deposit method.  This is very useful for some
very interesting but very hard to read hacks.  If someone is interested 
please let me know.


I am :)


Thanks ;)

Cédrick