Do me a favor, would you? Have a quick look at this code and tell me what you think it does...
...
I'm pretty confident that you'll find the second version a lot easier to understand, because it breaks up all those blocks of code into procedures with descriptive names.
But the real beauty of this procedure is a construct There are a couple of things you may find unfamiliar about this code. One is the use of a local map and local procedures. Just as you can (and almost always do) have a map in a program module, you can have maps within modules and within procedures.
Also each procedure is quite short because short blocks of code are generally easier to understand than long blocks of code.
The Hanson Loop
But the real beauty of this procedure is a construct Mike Hanson recently showed me, and which I've christened the Hanson Loop:
...
The beauty of the Hanson Loop is it provides a clear overview of the code being executed by the main procedure, while allowing for clean and efficient error handling. And this is where the Clarion error levels come inAt any time in the sequence of procedure calls a non-benign result will terminate the loop. Do you need to wrap this code in a transaction? It's as easy as doing a logout before the loop, and either a commit or a rollback depending on the value of Result.
Now, about those Clarion error levels.
The Clarion error levels
I will admit that it It has taken me years, almost nearly two decades really, to adopt Clarion error levels in my own coding.
I'm still doing so a bit grudginglyalmost completely convinced.
The Clarion help has this to say about error levels, in the context of the ABC ErrorManager object:
| Panel | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Six Levels of Treatment By default, the error manager recognizes six different levels of error severity. The default actions for these levels range from no action for benign errors to halting the program for fatal errors. The error manager also supports the intermediate actions of simply notifying the user, or of notifying the user and letting the user decide whether to continue or abort. Customizable Treatments These various levels of treatment are implemented with virtual methods so they are easy to customize. The error manager calls a different virtual method for each severity level, so you can override the default error actions with your own application specific error actions. See the various Take methods for examples. The recognized severity EQUATEs are declared in EQUATES.CLW. These severity levels and their default actions are:
You may define your own additional severity levels and their associated actions. |
These values specifically indicate what actions the ErrorManager may take. But there aren't quite as many of them as there may seem to be at first. Level:User appears nowhere in the ABC class library or the templates, other than as a definition. Level:Program is the same as Level:Fatal, and Level:Fatal means exit the program, so it's not something you're likely to use that often.. So that leaves Benign, Notify, and Cancel.
Over the years I've written may procedures and methods that returned a true/false value, and in those circumstances the Clarion error levels seemed overkill. Of the three really usable levels I seem to only need Benign and Notify, to signify True and False False. So why am I switching to not just use True and False?
In part I've adopted the Clarion error levels ? In part to be more in sync with the ABC classes, and in part because that does leave using levels leaves open the ability to indicate possibility of indicating different levels of success or failure, even if it's not a situation I come across often. But as soon as I do have one of those situations I suddenly become inconsistent, returning True/False in most of my code and three or more values in other code.
As you can see in the example with local procedures even I'm even using Level:Benign when there is only one potential return value, although I've mainly done that to make the code line up neatly and not because I suspect I will need a different value at some point. I could just as easily not assign a value to ReturnValue in any of the lines in the Execute statement - the loop will continue as before and will always move beyond those lines where ReturnValue is never assigned.
Summary
As I said you can always adapt the Hanson Loop to work with True/False values. That's not so important; what does matter is the Execute nested inside the Loop, and the use of local procedures to break up long blocks of code.
If you have long blocks of code that are difficult to understand, I highly recommend the Hanson Loop. Be descriptive in your procedure names, keep your procedures short, and your code will become easier to read and easier to maintain.