Given that the Whole Value used to quantify your business logic will exhibit subtle variations in behavior and that Exceptional Value may appear throughout the computations, it is possible that the methods you write will stumble in circumstances you cannot foresee.
Keep in mind that the rules of business apply only selectively, and that evolution of business practice wiggles around even those rules that "must" apply.
In your domain models you are chartered to express business logic with no more complexity than originally conceived or currently expressed.
Therefore:
Write methods without concern for possible failure.
Expect the input/output widgets that initiate computation to recover from failure and continue processing.
Output will remain blank because any other output would be an attempt to attach meaning to meaningless behavior.
Users will interpret unexpected blanks to mean that inputs do not apply and/or outputs are unavailable.
Trying to be meaningful:
weightedAverageCost | total weight | total := self weightedTotalCost. total isCurrency ifFalse: [^ExceptionalValue reporting: 'N/A']. weight := self totalWeight. (weight isNumber and: [weight isZero not]) ifFalse: [^ExceptionalValue reporting: 'Empty']. ^total / weight
Accepting possible meaninglessness:
weightedAverageCost ^self weightedTotalCost / self totalWeight
Note: some readers have assumed this pattern to be about writing error handlers. It is not. It is about writing domain methods in the presence of diversity. It does assume a near trivial error handler to be in place in the input/output system which has not always been the case.
You can view meaningless behavior as an alternate implementation of Exceptional Value and in many cases the two are indistinguishable to your user. Choose meaningless behavior unless a condition can be anticipated and has domain meaning (as opposed to merely operational meaning such as not-yet-filled-out).
At times there may be something very wrong inside the program so it is important that some clues surface.
Echo Back exposes failure by echoing blank.
Input screens that report Visible Implication can expect serious trouble to blank them too.
Deferred Validation should demand meaningful behavior where corruption of records is the alternative.