anyone familiar with Tyson Gill's error coding & layering?

[Hokkie]

Hi,

i am currently reading Tyson Gill's "Error Coding & Layering" for Visual Basic 6 and I'm wondering if anyone has any experience with his model of VB development... what he says seems to make sense and I'm wondering if anyone with hands-one experience agrees with that.

Thanks in advance!

when there's too much something is missing

 

[mmilan]

Since I haven't read the book, perhaps you could outline his model?

mmilan

 

[Hokkie]

Sure.

I won't go into details, but his model basically says that every line of code you write you should write for somebody else: "code is enduring".

This he implements by some basic laws:
-be as explicit as possible in your code;
-make routines as atomic as possible;
-prevent errors whenever possible (filtering user input, for example, or intensive validating of arguments before they are used);
-create clear error-messages when an error is prevented;
-trap errors that cannot be prevented.

This isn't very new, I agree. Where Gill's novel idea comes in is when he outlines his Safe Coding Framework. He distinguishes between three types of subroutines/functions:

Safe Functions;
Defensive Functions;
Defensive Subroutines.

The novel idea is that the Safe Functions do NOT return anything except a Safe Error Message. Any variables that need to be modified or returned must be given byref in its arguments.
A Safe Error Message is any kind of message that is either raised by VB itself or comes from converting and validating arguments (or any other error in the subroutine). If no error occured in the function, no value is returned. VB's own error messages are trapped and set in SEM form so that they are a part of the application's error-code rather than a side branch of it.

Defensive Functions are pretty much regular functions except that they are packed with error-coding (and error-preventing code) and are as atomic as possible. They return a 'regular' value, not a Safe Error Message. They have error-trapping as well.

Defensive Subroutines are also packed with error-prevening and error-handling code. They do not return a value, obviously, but can return something in their arguments. Defensive subroutines are a rarity in his model.

All arguments of these routines are always of type Variant! Inside the function extensive validation and conversion takes place. According to Gill, this makes the function as flexible as possible, and does not leave the responsiblity for calling the function to the calling routine. This seems to fly in the face of 'Coding Explicit', but Gill thinks flexibility and reusability take precedence over being explicit in argument-types. He does advocate the use of prefixes, like strName and intNumber and so on.

He also advices to use wrappers around VB's functions as much as possible.

I am getting into this material and trying it out. It seems like a lot of work but I must say that the routines I am (re)writing now I am (re)writing for all future use. They are no longer terribly specific for my application (although some are, obviously).

Hope you're still awake,
Hokje

 

[mmilan]

Interesting...

I tend to avoid variants, as all manner of mischief lies down that path. If my program function is designed to accept an integer for example, then I code it with an integer parameter. Any muppet who calls it with a string deserves everything that's coming.

Errors are not necessarily bad things - in the case of Type MisMatch, they can prevent people trying to do things that you'd rather they didn't.

That having been said, I am trying to move more toward C++ and Java with my thinking these days, both of which a fairly strongly typed languages.

Aside for the variants thing, I do like his model. Unfortunately I work on a VAST project in VB, so I can't simply re-write everything, but what he says does make sense.

When I had my first programming job I never used On Error. Every time a user had an error, I'd investigate how it occurred and then code around it. The result was some very good (ie. everything got checked), though very long code.

These days I work to a simpler ideal in my own programs. Namely:
1/ Everything, and I do mean EVERYTHING, will fall under an On Error.
2/ All my subs / functions have a single exit point.

I've learned a lot through being involved in a large scale project - it's surprising what you cn pick up by simply browsing other people's code...

mmilan.

 

[Hokkie]

>Any muppet who calls it with a string deserves everything
>that's coming.



>Errors are not necessarily bad things - in the case of
>Type MisMatch, they can prevent people trying to do
>things that you'd rather they didn't.

You're right--errors aren't necessarily bad things. But if you can prevent users or other programmers from doing things you don't want them to do, well... that's even better, isn't it?

One thing I like rather a lot about having Variants in your arguments is that a routine can then deal with different kinds of arguments... rather like overloading, something you'll have met in C++ and Java, but which is completely lacking in VB (or is it available in .NET?)

Reading that he proposes variants for all arguments certainly made me shift uneasily. But, being willing to learn I thought I'd give it a try. Part of the reason for using variants is that you can never know what the calling routine will give you in the future (not at the moment of coding, usually). So giving the calling routine some freedom in calling without having to convert variables and doing extensive conversion and validating on passed arguments in the routine seems like a good idea to me. It also forces you to thouroughly validate all arguments.

If your routine expects an integer and the calling routine gives it a string, well... it's not a problem if the string is numeric (when using variants). If it's not numeric, a Safe Error Message will take care of that. This does depend on well-coded conversion and validation routines, but once they're in place... It also does not stop execution (necessarily).

But hey, maybe in a few month's time I'm on my face wondering how on earth I could have typed 'As Variant' so often.

The Safe Error Message model seems to work well for now. I guess the real deal is when a team of programmers is working on a project over a few generarions (both of the application and the team). For the quick and dirty applications there's no real need. But somewhere in the back of my head Gill is saying: "There should be no such thing as a quick and dirty application.