Goal Failure In Programming

I am starting a query to learn the current state of "programming bearing goal failures in mind". I was rereading Wards CHECKS pattern called MeaninglessBehavior? (http://c2.com/ppr/checks.html#3), which shows an example of trying to write code that anticipates operation failure. I just finished skimming the book on the programming language Icon (see Ward's *very* short example of an Icon program in LinearShuffle), and the thing that struck me was that Icon is built around the notion that every operation can succeed or fail, and you write the program taking advantage of this.

I get to this query from goal-based use cases. I find it interesting that we are starting to express functional requirements in scenarios, each step of which is a goal and where each goal can fail, often in multiple, interesting ways. The functional requirements for a system must provide explanation for what to do in most of these very many goal failure conditions. Use cases written this way are clearly procedural programs, written in prose, with sequential, alternative, parallel paths, and exception handling. Ordinary people have little trouble writing such use cases, which in contrast with the difficulty I for one have reading code written with exception/try/throw/catch.

I also am starting to see Java code written with exceptions all over the place.

So that gets me to the hope for this page, that someone will add some notes on programming languages or programming techniques related to programming with goal failure in mind. Is there a way to make it readable? is the foremost question on my mind, along with What are some existing mechanisms that allow for and take advantage of it. Cheers - AlistairCockburn

I think that the main difference between Java and other languages I know (eg C, C++) is that Java tries to separate the exceptional from the expected. It does not necessarily succeed.

If you look at the Java API, an Exception 'indicates conditions that a reasonable application might want to catch.' FileIOException, and an Error 'indicates serious problems that a reasonable application should not try to catch'. Both get thrown from anywhere in the code, and both mean that something has gone wrong that is outside the normal scope of the program. If something is expected to happen, (eg ATM application; you have not got enough money to withdraw what you want) the API implies that you don't throw an exception. Exceptions should be events that are not expected in the course of a tested application, but might happen because of something outside the application's control (eg someone cuts the network cable, the file system has wrong permissions set, or the database dies).

Exceptions often get used as messages (I have done so myself), but this is mostly because methods tend to get written with constrictive return values that can't pass enough information back (eg primitives). In C/C++, primitives are used to indicate success/failure/exception.

Given the above, operation failure is anticipated by writing methods with useful return values (array or Collection of ValueOjects?), or that message the work flow another way (eg write results to a message queue, or work flow status area). System failure is anticipated by throwing and catching exceptions.

I would like to know how SmallTalk handles this. - WillChamberlain