text:
Formal Logic/Sentential Logic/Validity

Satisfaction
In sentential logic, an interpretation under which a formula is true is said to satisfy that formula. In predicate logic, the notion of satisfaction is a bit more complex. A formula is satisfiable if and only if it is true under at least one interpretation (that is, if and only if at least one interpretation satisfies the formula). The example truth table of Truth Tables showed that the following sentence is satisfiable.

 * $$\mathrm{P} \land \mathrm{Q} \rightarrow \lnot( \mathrm{Q} \lor \mathrm{R})$$

For a simpler example, the formula $$\mathrm{P}\,\!$$ is satisfiable because it is true under any interpretation that assigns $$\mathrm{P}\,\!$$ the value True.

We use the notation $$\mathfrak{v} \vDash \varphi$$ to say that the interpretation $$\mathfrak{v}\,\!$$ satisfies $$\varphi\,\!$$. If $$\mathfrak{v}$$ does not satisfy $$\varphi,$$ then we write $$\mathfrak{v} \not\vDash \varphi.$$

The concept of satisfaction is also extended to sets of formulae. A set of formulae is satisfiable if and only if there is an interpretation under which every formula of the set is true (that is, the interpretation satisfies every formula of the set).

A formula is unsatisfiable if and only if there is no interpretation under which it is true. A trivial example is

 * $$\mathrm{P} \land \lnot \mathrm{P}\,\!$$

You can easily confirm by doing a truth table that the formula is false no matter what truth value an interpretation assigns to $$\mathrm{P}\,\!$$. We say that an unsatisfiable formula is logically false. One can say that an unsatisfiable formula of sentential logic (but not one of predicate logic) is tautologically false.

Validity
A formula is valid if and only if it is satisfied under every interpretation. For example,

 * $$\mathrm{P} \lor \lnot \mathrm{P}\,\!$$

is valid. You can easily confirm by a truth table that it is true no matter what the interpretation assigns to $$\mathrm{P}\,\!$$. We say that a valid sentence is logically true. We call a valid formula of sentential logic—but not one of predicate logic—a tautology.

We use the notation $$\vDash\varphi$$ to say that $$\varphi$$ is valid and $$\not\vDash\varphi$$ to indicate $$\varphi$$ is not valid.

Equivalence
Two formulae are equivalent if and only if they are true under exactly the same interpretations. You can easily confirm by truth table that any interpretation that satisfies $$\mathrm{P} \land \mathrm{Q}\,\!$$ also satisfies $$\mathrm{Q} \land \mathrm{P}\,\!$$. In addition, any interpretation that satisfies $$\mathrm{Q} \land \mathrm{P}\,\!$$ also satisfies $$\mathrm{P} \land \mathrm{Q}\,\!$$. Thus they are equivalent.

We can use the following convenient notation to say that $$\varphi\,\!$$ and $$\psi\,\!$$ are equivalent.

 * $$\varphi\,\!$$ [[Image:EquivalenceSign.png]] $$\psi\,\!$$

which is true if and only if

 * $$\vDash\ (\varphi \leftrightarrow \psi)\,\!$$

Validity of arguments
An argument is a set of formulae designated as premises together with a single sentence designated as the conclusion. Intuitively, we want the premises jointly to constitute a reason to believe the conclusion. For our purposes an argument is any set of premises together with any conclusion. That can be a bit artificial for some particularly silly arguments, but the logical properties of an argument do not depend on whether it is silly or whether anyone actually does or might consider the premises to be a reason to believe the conclusion. We consider arguments as if one does or might consider the premises to be a reason for the conclusion independently of whether anyone actually does or might do so. Even an empty set of premises together with a conclusion counts as an argument.

The following example show the same argument using several notations.

 * Notation 1
 * $$\mathrm{P}\,\!$$
 * $$\mathrm{P} \rightarrow \mathrm{Q}\,\!$$
 * Therefore $$\mathrm{Q}\,\!$$

 * Notation 2
 * $$\mathrm{P}\,\!$$
 * $$\mathrm{P} \rightarrow \mathrm{Q}\,\!$$
 * ∴ $$\mathrm{Q}\,\!$$

 * Notation 3
 * $$\mathrm{P}\,\!$$
 * $$\underline{\mathrm{P} \rightarrow \mathrm{Q}}\,\!$$
 * $$\mathrm{Q}\,\!$$

 * Notation 4
 * $$\mathrm{P},\ \mathrm{P} \rightarrow \mathrm{Q}\,\!$$ ∴  $$\mathrm{Q}\,\!$$

An argument is valid if and only if every interpretation that satisfies all the premises also satisfies the conclusion. A conclusion of a valid argument is a logical consequence of its premises. We can express the validity (or invalidity) of the argument with $$\Gamma\,\!$$ as its set of premises and $$\psi\,\!$$ as its conclusion using the following notation.

 * (1)   $$\Gamma \vDash \psi\,\!$$
 * (2)   $$\Gamma\ \not\vDash\ \psi\,\!$$

For example, we have

 * $$\{\mathrm{P},\ \mathrm{P}\rightarrow\mathrm{Q}\}\ \vDash\ \mathrm{Q}\,\!$$

Validity for arguments, or logical consequence, is the central notion driving the intuitions on which we build a logic. We want to know whether our arguments are good arguments, that is, whether they represent good reasoning. We want to know whether the premises of an argument constitute good reason to believe the conclusion. Validity is one essential feature of a good argument. It is not the only essential feature. A valid argument with at least one false premise is useless. Validity is the truth-preserving feature. It does not tell us that the conclusion is true, only that the logical features of the argument are such that, if the premises are true, then the conclusion is. A valid argument with true premises is sound.

There are other less formal features that a good argument needs. Just because the premises are true does not mean that they are believed, that we have any reason to believe them, or that we could collect evidence for them. It should also be noted that validity only applies to certain types of arguments, particularly deductive arguments. Deductive arguments are intended to be valid. The archetypical example for a deductive argument is a mathematical proof. Inductive arguments, of which scientific arguments provide the archetypical example, are not intended to be valid. The truth of the premises are not intended to guarantee that the conclusion is true. Rather, the truth of the premises are intended to make the truth of the conclusion highly probably or likely. In science, we do not intend to offer mathematical proofs. Rather, we gather evidence.

Formulae and arguments
For every valid formula, there is a corresponding valid argument having the valid formula as its conclusion and the empty set as its set of premises. Thus

 * $$\vDash \psi\,\!$$

if and only if

 * $$\varnothing \vDash \psi\,\!$$

For every valid argument with finitely many premises, there is a corresponding valid formula. Consider a valid argument with $$\psi\,\!$$ as the conclusion and having as its premises $$\varphi_1, \varphi_2, ..., \varphi_n\,\!$$. Then

 * $$\varphi_1,\ \varphi_2,\ ...,\ \varphi_n \vDash \psi\,\!$$

There is then the corresponding valid formula

 * $$\varphi_1 \land \varphi_2 \land ... \land \varphi_n \rightarrow \psi\,\!$$

There corresponds to the valid argument

 * $$\mathrm{P},\ \mathrm{P} \rightarrow \mathrm{Q}\,\!$$ ∴  $$\mathrm{Q}\,\!$$

the following valid formula:

 * $$\mathrm{P} \land (\mathrm{P} \rightarrow \mathrm{Q}) \rightarrow \mathrm{Q}\,\!$$

Implication
You may see some text reading our arrow $$\rightarrow\,\!$$ as 'implies' and using 'implications' as an alternative for 'conditional'. This is generally decried as a use-mention error. In ordinary English, the following are considered grammatically correct:

 * (3)   'That there is smoke implies that there is fire'.
 * (4)   'There is smoke' implies 'there is fire'.

In (3), we have one fact or proposition or whatever (the current favorite among philosophers appears to be proposition) implying another of the same species. In (4), we have one sentence implying another.

But the following is considered incorrect:

 * There is smoke implies there is fire.

Here, in contrast to (3), there are no quotation marks. Nothing is the subject doing the implying and nothing is the object implied. Rather, we are composing a larger sentence out of smaller ones as if 'implies' were a grammatical conjunction such as 'only if'.

Thus logicians tend to avoid using 'implication' to mean conditional. Rather, they use 'implies' to mean has as a logical consequence and 'implication' to mean valid argument. In doing this, they are following the model of (4) rather than (3). In particular, they read (1) and (2) as '$$\Gamma\,\!$$ implies (or does not imply) $$\psi\,\!$$.

title: Formal Logic/Sentential Logic/Validity


text:
User:Csherbak

I am a NeoPagan Druid Bear living in Chicago, IL, USA with my partner Jack.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: User:Csherbak


text: User:Gryn~enwikibooks

title: User:Gryn~enwikibooks


text:
A Neutral Look at Operating Systems/Microsoft Windows

Windows is the most widely used OS for home and business desktop use, and thus is well supported by software developers. Early versions of Windows were based on Microsoft's DOS (Disk Operating System), and were therefore not designed with persistent network connections in mind (unlike UNIX; see below). This posed a problem for Windows' growth because as persistent network connections have become more commonplace, so have the risks of viruses, malware and other security breaches. A major redesign that began with Windows NT aims to address this.

Windows 1, Windows 2, Windows 3, Windows 3.1, Windows 3.11, Windows 3.12
These early versions of Windows were based (concurrently with Apple's) on the XEROX PARC concept of WIMPS (Windows, Icons, Menus, Pointing System) and were little more than a pretty Graphical User Interface on top of MSDOS. In fact, versions in the 1.x and 2.x families had as their main shell a text-based directory listing, and their programs do not work on newer versions of Windows. The early versions were not popular: most users stayed with DOS until Windows 3.1 came along with rather simple networking support. Novell and others exploited the opportunity that Microsoft had left, but they failed to recognise the emerging Internet Standard, TCP/IP. This critical error allowed Microsoft to regain control, albeit with little concern at the time for complete and secure implementations.

Windows 95, Windows 98, Windows 98 SE, Windows Me
Windows 95 introduced pre-emptive multitasking to the consumer Windows family. This was very important at the time, as Windows had gained (with hindsight, unfairly) a reputation for being unstable; in reality, however, the large majority of the errors were in the applications and third-party drivers that Windows ran. Pre-emptive multitasking allowed for an application to fail without bringing down the whole machine. Nevertheless, these versions of Windows still lacked adequate housekeeping, such that a failing application could leave the memory in such a mess that a reboot was needed. In practice, however, most people using commercial applications saw relatively few crashes. Three fundamental problems remained: All of these made the world's most popular operating system a sitting duck for malware authors. However, as Windows became more popular as a malware target, some other OS's seem to have lagged in security as well since they are very rarely targeted.
 * there was no hard wall preventing a user application to run at kernel level;
 * there was nothing to distinguish data memory from instruction memory; and
 * there was no concept of Administrator or Super-user; ordinary users had full control but lacked the knowledge to manage it. The system was delivered with critical TCP/IP functions exposed.

Windows NT, Windows 2000, Windows XP, Windows 2003
The availability of 32-bit memory addressing allowed Microsoft to redevelop large parts of the OS to meet the standards needed to drive on the "Information Superhighway". Top software designers were headhunted from Digital Equipment Corporation to redesign the OS from the ground up. They designed and developed Windows NT ("New Technology"), discarding much of the DOS framework. Windows NT is, by design, more secure than previous versions of Windows. Microsoft eventually phased out all DOS-based versions of Windows in favor of the NT-based varieties. Windows 2000, Windows XP, Windows 2003, and Windows Vista are all based on Windows NT architecture.

 * As an interesting sidenote, Windows NT (WNT) was marketed as "Windows New Technology", and was often guessed by users to be "Windows Networking Technology" because networking was made native to Windows NT. It has later been disclosed, however, that WNT was actually a play on VMS (another operating system) - in the same manner as 2001: A Space Odyssey's HAL was supposedly a play on IBM.

In designing the Windows operating systems, Microsoft had decided that user friendliness was the main goal of the design. As a side effect, Windows systems generally did not have adequate security settings enabled by default, even in NT-based versions until the release of Windows XP SP2 and Windows Vista, and therefore could still be compromised if connected "out-of-the-box" to the Internet directly. In fact, many users have complained that their computers became infected with various worms and viruses even while installing Windows XP. However, since the release of Windows Vista - the first Microsoft operating system to be developed using the Trust Computing Development Lifecycle, these problems have largely become irrelevant. Windows includes software for sharing an Internet connection between Windows computers connected on the same network, as well as rudimentary firewall software for protecting the network. Since Windows Vista, Microsoft ships an anti-spyware solution built-in and a free anti-virus solution called Microsoft Security Essentials is currently in beta, with plans to be made available for free to all users of Genuine Windows. For even better security (usually recommended for home or small business networks), a separate hardware-based switch with an integrated firewall is a wiser solution. Such hardware can be purchased for as little as $30 US. (This security measure can, in fact, be used with any operating system, not just Windows.)

A 2008 study comparing the source code quality of Linux, the Windows Research Kernel (a derivative of the Windows 2003 Kernel), FreeBSD and Solaris found that the quality of code was roughly equivalent

See Windows Software. Windows NT and VMS: The Rest of the Story.

ReactOS
ReactOS is a project attempting to create a Windows compatible open-source operating system. It uses no code from Microsoft Windows and is completely open-source. It also is not based on Linux, however some code is carried over from the Wine project which runs on Linux. Currently it is in alpha stage and not suitable for production systems.


text:
User talk:24.190.15.117

--Cspurrier 03:36, 23 August 2005 (UTC)

You have been blocked from editing for 24 hours. If you continue to vandalize Wikibooks after the block expires, then you will be blocked for longer. Geo.T 04:32, 23 August 2005 (UTC)

title: User talk:24.190.15.117


text:
Muggles' Guide to Harry Potter/Characters/Hedwig

Overview
Hedwig is Harry's pet owl. Since mail is delivered by owls in the wizarding world, she plays a valuable role in Harry's life. More than that, however, she is one of Harry's companions; sometimes Harry feels that Hedwig is the only friend he has left.

Philosopher's Stone
Harry is allowed to bring a toad or a cat or an owl to school, according to the book-list. Hagrid, who is guiding him through Diagon Alley, decides to buy Harry an animal as a birthday present. Toads, he says, are old-fashioned and would get him laughed at, and he doesn't like cats, because he says they make him sneeze, so he takes Harry to Eeylops Owl Emporium and buys him a snowy owl. Back at the Dursleys' home, Harry decides to name his owl Hedwig, a name he had found in his History of Magic text.

At King's Cross Station, as he tries to find Platform Nine and Three Quarters, Harry feels that Hedwig's cage on top of his luggage cart makes him seem out of place. When he sees another family walking past, talking about Muggles, he begins to hope they might be able to show him the way to the platform, but he only dares approach them when he sees one of them also has an owl in a cage. We will later learn that this is the Weasley family, and the owl in question is Hermes, who belongs to Percy.

During the first week of school, Hedwig occasionally flies in with the post owls at breakfast, to nibble affectionately at Harry's ear and get a bit of toast before going off to sleep in the Owlery. On Friday, she brings a note from Hagrid, inviting Harry to tea after class. Harry immediately sends a response back saying he'd be glad to.

When Harry, Ron, and Hermione plan to get Charlie Weasley to take Hagrid's pet dragon, Norbert, to Romania to release it back into the wild, it is Hedwig who brings Charlie's response back to the Trio. From this we can assume that it was Hedwig who carried the request to Charlie.

In the chamber with the logic puzzle, Harry instructs Hermione to return to the Owlery and send Hedwig with a message for Dumbledore. It turns out that Hermione never gets that far, meeting with Dumbledore in the Entrance Hall.

Chamber of Secrets
Because Uncle Vernon doesn't want strange things happening at his house, he refuses to let Hedwig hunt; he has locked her into her cage. Harry is locked into his room after the disastrous visit of the Masons on the evening of his birthday. We see Harry giving Hedwig most of his vegetable soup, and see her disapproval. When the Weasleys arrive to rescue Harry, he nearly forgets Hedwig; her loud hoots at being nearly abandoned wake Vernon up, and he charges into Harry's room just too late to catch Harry. The twins have taught Harry how to pick locks with a hairpin, and Harry opens Hedwig's cage; she flies alongside the car for some distance.

Prisoner of Azkaban
Hedwig's time over the summer has changed slightly, as she's now allowed out at night; Uncle Vernon having given in due to the racket she makes in her cage. She helps a school owl carry Errol up to Harry's bedroom with a birthday present from Hermione.

Hedwig had sent Harry a letter, from Hagrid, but he doesn't notice, so she gets his attention by nibbling him sharply, during that time, Neville gets sent a howler, and he runs out of the Great hall, then, Hedwig helps herself with Neville's cornflakes, and sets off for the Owlery

Goblet of Fire
After having what he thought was a nightmare, which resulted in his scar hurting, Harry sends Hedwig off with a letter to Sirius Black, but she doesn't return to him till after the Quidditch World Cup. Harry then sends her back with another letter to Sirius, telling him he only imagined the hurting, hoping it'll stop him from returning to Britain, but she soon comes back to Harry with a second letter from Sirius, who doesn't believe the lie.

When Harry writes to Sirius about being made the fourth Triwizard Champion, Hedwig moves to get the letter, but Harry tells her he can't use her; Sirius having told him to keep changing owls as she's too easily recognized, to her annoyance.

Order of the Phoenix
After the Dementor attack at Little Whinging, Harry writes letters to Sirius Black, Ron, and Hermione, demanding an explanation. Hedwig is out hunting; when she returns with a frog she has caught, Harry immediately sends her away with the letters, and instructions to peck at the recipients until they have written good long letters to send back to him. She leaves straight away, still clutching her frog, and Harry regrets having sent her away, as she is the only sympathetic person at 4 Privet Drive. He expects her prompt return, but she does not reappear.

Hedwig flies down from her perch on top of a wardrobe and lands on Harry's shoulder when Harry arrives at Number 12, Grimmauld Place, where she had stayed after delivering the messages Harry had given her. Harry is very glad to see her, and keeps stroking her even while speaking angrily to Ron and Hermione, who both show signs of Hedwig having pecked them. When Harry gets too angry, Hedwig retreats, reproachfully, to the top of the wardrobe.

After the meeting that evening, Hedwig and Pigwidgeon are clattering around on top of the wardrobe. Ron throws some Owl Treats up there for them, explaining that Dumbledore doesn't want them out hunting too often, it would raise questions.

On the last day before the start of classes, Harry climbs on a chair to clean all the owl droppings off the top of the wardrobe. Finishing, he tosses the accumulated owl droppings into a wastebasket, which swallows them and belches loudly. During the conversation that follows, the wastebasket occasionally makes soft gagging noises as it coughs up the owl droppings. Hermione borrows Hedwig at this point to send her parents the news that she has been made a Prefect.

Hedwig returns just before everyone leaves for the Hogwarts Express, and obligingly flutters off Hermione's shoulder and over to her cage as Harry finishes packing. At an angry call from Mrs. Weasley downstairs, Harry stuffs her unceremoniously in her cage and carries her and his trunk downstairs.

Harry travels to King's Cross Station with a number of members of the Order, and does not see Hedwig again until Mad-Eye Moody, in porter's uniform, brings her and all the luggage to Platform Nine and Three Quarters.

Once on the Hogwarts Express, Hedwig stays in the compartment with Harry, and is disturbed by Luna Lovegood's screams of laughter when Ron jokes about the lines he plans to give to Goyle.

When Harry's scar pains him at the end of his fourth detention with Professor Umbridge, Harry writes a coded letter to Sirius to ask for advice. He carefully tells Hedwig that although the letter is addressed to Snuffles, it is really for Sirius. Hedwig blinks, which Harry takes to be understanding, and flies off from the Owlery.

The day after the initial meeting of what becomes Dumbledore's Army in the Hog's Head, a bedraggled Hedwig appears at the window of Harry's History of Magic class. Harry lets her in, then, finding her injured, asks Professor Binns for permission to go to the Hospital Wing as he doesn't feel well. Getting grudging permission, he instead goes to the staff room, where he finds Professor McGonagall. Hearing that Harry has an injured owl, Professor Grubbly-Plank also comes to the door, and she in turn takes Hedwig, saying she'll get Hedwig all fixed up. McGonagall reminds Harry of the message on Hedwig's leg, then quietly warns him that all communications in and out of the school are monitored. Hedwig, meanwhile, seems to feel that Harry is abandoning her.

The message on Hedwig's leg proves to be from Sirius, and reads simply "Tonight, same time, same place." When Sirius is nearly caught in the Gryffindor common-room fire by Umbridge, Hermione guesses that it was on Umbridge's order that Hedwig had been intercepted.

Hedwig, with her injuries healed, is brought back to the Gryffindor common room and returned to Harry by Dobby. It is then that Dobby tells Harry how to find the Room of Requirement.

Hedwig and Pigwidgeon are then not seen again until the trip back to London on the Hogwarts Express. It is noted that Hedwig and Pigwidgeon are disturbed by Ron's outburst when he learns that Ginny is going out with Dean.

Deathly Hallows
Hedwig, when we first see her, is sulking, either asleep or pretending. Harry knows that it is because she has been allowed so little time outside her cage in the past short while. When Harry pushes a couple of owl nuts through the cage bars to her, she ignores them. She remains unmoving while Harry, possibly in jest, shows her the places around the house at Privet Drive that hold memories for him.

Climbing into the sidecar of Sirius' flying motorcycle, Harry finds very little room for himself and even the few possessions he is taking with him. He ends up with his rucksack tucked uncomfortably under his feet, and Hedwig, in her cage, on his knees.

Trying to avoid the first strike of the Death Eaters, Hagrid turns the motorcycle so sharply that it turns upside down; Harry has to grab for Hedwig's cage and the rucksack, and watches his Firebolt fall to earth. Green flashes fly past, and Hedwig falls dead to the bottom of her cage. When the sidecar breaks free of the motorcycle, Harry manages to keep it in the air while Hagrid loops around to pick him up, but Harry can only take his rucksack. To disable one of the following Death Eaters, Harry destroys the sidecar, feeling a dreadful pang of regret for Hedwig as he does so.

As they wait for the Portkey to activate to take them to The Burrow from the house of Tonks' parents Ted and Andromeda, Hagrid asks Harry about Hedwig, and is shocked to hear that she has been killed.

In the Forest of Dean, Harry hears an owl hoot and is reminded of Hedwig.

Strengths
Hedwig is exceptionally intelligent for an owl, being able to follow more complex instructions such as to "keep pecking them until they've written decent-length answers", and to carry deliberately misaddressed packages (e.g. a package addressed to "Snuffles" was carried to Sirius). She also fought to get away from Umbridge, despite being wounded, suggesting that she is capable of loyalty and other "human" emotions.

Weaknesses
Hedwig is a snowy owl, very beautiful but easily seen and recognized. Snowy owls are not native to Britain and Hedwig was known to belong to Harry. Therefore, Harry could not use Hedwig to deliver messages when security and anonymity were required. Hedwig was easily offended and sulked when Harry used other owls for messages to Sirius.

Hedwig was a headstrong and proud owl who displayed an exaggerated sense of propriety. Hedwig quite obviously disapproved of the undignified enthusiasm of Ron's owl Pigwidgeon.

Relationships with Other Characters
Hedwig is very loyal to Harry Potter. During Harry's summer breaks at the Dursleys', Hedwig is often Harry's only companion and link to the Wizarding World. For Harry's sake, particularly in the early years, Hedwig puts up with quite a bit of discomfort and deprivation through the summer months at Privet Drive.

When Harry had loaned Hedwig to others, Hedwig seemed to accept the situation easily. For instance, when he loaned her to Hermione so that she could pass the news of her becoming a Prefect to her family, Hedwig quite cheerfully rode her shoulder while the message was being prepared, then returned to Hermione until Hermione brought her back to Harry.

Hedwig seemed sympathetic to the plight of Errol, the Weasley family's geriatric owl, at one point allowing Errol to share her perch, water, and food, and on another occasion actually helping Errol carry a package to Harry. Towards the over-exuberant Pigwidgeon, however, she seemed to show much more disdain, and went to great lengths to demonstrate how a post owl ought to behave.

Analysis
An uncanny amount of intelligence has been ascribed to owls in general in the Wizarding world. Implicit in their use as postal carriers is the suggestion that they can read and interpret written addresses, and given a name locate the corresponding wizard – in Hedwig's case, even if it is an alias. Owls are assigned an almost human level of understanding in fact, noticing that other owls may need help in fulfilling their missions, and with awareness that they are being rejected in favour of other letter-carriers, though perhaps without the ability to understand why.

It may be that Hedwig's apparent intelligence was considered a plot necessity by the author. It's certainly true that on several occasions, Harry feels rejected by everyone at Hogwarts, and Hedwig is the only companion he can turn to. Whether a less-intelligent pet would have provided the necessary solace is uncertain; it is obvious, however, that Hedwig's ability to be affronted and to react in somewhat sentient manner to Harry's requests does add drama and depth to their relationship.

J.K. Rowling, in interviews, has stated that snowy owls, unlike most other breeds, are diurnal and so would normally be sleeping at night, a thing she was not aware of when she decided Hedwig's breed. She has also described the death of Hedwig as the end of Harry's innocence. Hedwig died four days before Harry came of age at 17 years old.

Greater Picture
Harry found the name "Hedwig" in his textbook A History of Magic. In Muggle history there is a Saint Hedwig, who was the Duchess of Silesia and was canonized in 1267. The Sisters of St. Hedwig was founded in 1859 and are dedicated to the education of orphaned and abandoned children, children not unlike Harry.


text:
Talk:Japanese/Lessons/Personal suffixes and name usage

Untitled
For the beginner, I think that -san, -sama, -chan, -kun, and -sensei are probably more than adequate. The other honorifics should be moved to a different page.

This page also has way too much explanation and almost no examples. I think that a beginning student would find this page very hard to understand.

 * Alternatively, we could keep them on this page, but put them under a new section such as "rarely used honorifics". This way they are all in place, but the reader knows that they should just familiarise themselves with the suffixes, but not to bother studying/memorising them. – Sik0fewl 16:42, 23 August 2005 (UTC)

 * Ah, yeah like we did on the personal pronoun page. OK. If you are faster than me, you may do that separation, marking the rest as additional. I can do it at the end of the week. --lastguru 18:53, 23 August 2005 (UTC)

 * just do not say "rarely used", just additional or less used or something like that, because they are not entirely rare, and as our course is deep, as opposed to easy fast, I would really like it to list at least as much usable information as I did. --lastguru 18:57, 23 August 2005 (UTC)

 * oh well, wanted to put one deletion back, so separated the lists by the way. if you want a note there - put it :) ... --lastguru 23:02, 23 August 2005 (UTC)

Is there going to be a dialogue or some other language resource that the the student will be looking at while studying honorifics? - ToothingLummox 11:47, 25 August 2005 (UTC)


text:
Optics/Nature of light

Introduction to Light
Light is actually a form of radiation. In fact, radiation isn't always a bad thing. Some of it is actually quite useful like light, microwaves and radio waves. Those are some of the types of electromagnetic radiation you encounter everyday. You probably guessed by now that light is a type of wave. Well, it is! But at the same time, it also has particle-like characteristics. In this section, we will examine the nature of light and whether it is a wave, a particle or both.

The Electromagnetic Spectrum
To understand light, we need to understand the electromagnetic spectrum. Basically, this spectrum shows different forms of electromagnetic radiation and where they belong on the spectrum. There are a few trends to the spectrum which will be discussed later.

What is Electromagnetic Radiation?

A lot of people seem to associate radiation with nuclear waste and things that cause cancer. However, in science, it has a much more general definition. Radiation is a way to transfer energy and have it propagate, or spread out, as it travels.

Now that you know light is a form a radiation, you can see evidence of this every time you use a flash light. Notice how the beam's diameter increases the farther it is away from the source? This is a property of a wave (which will be discussed in more detail in section 1.1.1 - What is a wave?).

As for the "electromagnetic" part, that refers to the fluctuating electric and magnetic fields that make up the waves. The Speed Limit of the Universe

The Speed Limit of the Universe

Aside from the fact that all EM (electromagnetic) radiation are composed of varying electric and magnetic fields that spread out as they travel, there is one other very important similarity between all of them; they all travel at the speed of light.

The fact that there is a speed of light means that light does not appear instantaneously, as opposed to what some great minds thought in ancient times. The speed of light, which is usually denoted with the letter $$c$$, is $$299.792.458 \ \text{m/s}$$ or about $$186.000 \ \text{mi/s}$$. That is fast enough to past through the center of the Earth and reach the other side in about $$1/50^{\text{th}}$$ of a second. Just imagine how difficult it was to measure the speed of light back then!

The reason why the speed of light is so important is because it is the fastest speed in the universe. Nothing can surpass it. Which is why sometimes it is considered "the speed limit of the universe". Different Forms of EM Radiation

Different Forms of EM Radiation

Now that you know some of the similarities between all EM radiation, you're probably wondering what the difference is. The difference could be explained in three different ways:

 * 1) Wavelength;
 * 2) Frequency;
 * 3) Energy.

In this section we will only talk about energy. The other two, wavelength and frequency, will be discussed later in section 1.1.1 - What is a wave?

If you take a look at the spectrum, you will see "low energy radiation" and "high energy radiation" labelled on the diagram. Obviously, this indicates that radiation near the top, like radio waves and microwaves have low energies while radiation near the bottom, like x-rays and gamma rays, have high energies. That is the only difference between all EM waves; they differ by their energy levels.

As you can see, light is a very small part of the electromagnetic spectrum. Even within that small region, it could be isolated and referred to as a "sub-spectrum", this one, however, you should be more familiar with.

The Colors of the Rainbow

This "sub-spectrum" or the range of visible light occupies a very small part of the EM spectrum. Compared to the other types of EM radiation, it takes up the least space on the spectrum.

That small region, however, is split up into all the different colors of the rainbow. Starting from red and ending at violet. This range must also be consistent with the EM spectrum since it is within it, therefore, red is the lowest energy color and violet is the highest energy color. All of this is shown in the diagram above.

Have you ever heard that white and black are not considered colors? Well, that's true. White is actually a combination of all the colors and black is the absent of all the colors. You can see the effects of this when a prism splits up white light into its component colors.

Light as a Particle
So far, we have discussed light in terms of being a wave. But what about its particle-like characteristics?

To begin, you need to know what a photon is. A photon is a massless particle that travels at the speed of light and carries a certain amount of energy, which we call a quantum (pl: quanta). EM Radiation could also be considered a stream of photons, each carrying a certain amount of energy. The more energetic the radiation is, the more energy its photons are carrying. For example, photons of red light carry less energy that photons of violet light.

Wave-Particle Duality
So you're probably anxious to answer the question "which is it: wave or particle"? Either that, or you're anxious to finish reading this article.

Well, the truth is, the question cannot be easily answered. Light can exhibit both wave and particle characteristics. This concept is known as the "wave-particle duality" and it is the reason why modern physics or quantum physics was invented.

This leads us to the next section of the wikibook, entitled "Light - Wave or stream of particles?" If you think this section is confusing, you haven't seen anything yet. The next section enters the mysterious world of quantum mechanics: a world that has puzzled many great minds in the past, including a brilliant physicist named Albert Einstein.

title: Optics/Nature of light


text:
Talk:An Introduction to Weblogs

If you're interested, we've put together a good workshop/tutorial for teachers learning about blogging. See Getting Started with Blogging in Education. -Michael

Surely the 1977 date for the list of 23 canonical blogs is a typo. 71.253.36.13 05:44, 1 December 2007 (UTC)

title: Talk:An Introduction to Weblogs


text:
Category:Pea recipes

Recipes involving peas.

title: Category:Pea recipes


text:
Biblical Studies/Christianity/Overview

Significant wikis on Christianity
''Notice: Wikibboks does not officially sanction any of the following. Use at your own risk.''
 * WikiChristian - A wiki for Christians to discuss the Bible, current issues in the church, church history, Christian music and movies, and Christian doctrine and theology.

Chapter 1: The essence of Christianity

 * ../The essence of Christianity/
 * ../God the father/
 * ../Jesus/
 * ../Holy Spirit/
 * ../Becoming a Christian/
 * ../Living as a Christian/

Chapter 2: Christian texts and writings and the arts

 * ../The Bible/
 * ../Creeds and catechisms/
 * ../Famous ancient Christian texts/
 * ../Famous works of fiction/
 * ../Famous works of non-fiction/
 * ../Christian music/
 * ../Christian movies and television/

Chapter 3: Church history

 * ../Major events and important movements in church history/
 * ../Famous Christians/
 * ../Authors/
 * ../Bible Characters/
 * ../Evangelists/

Chapter 4: Denominations

 * ../An introduction to denominations/
 * ../Eastern Orthodoxy/
 * ../Roman Catholicism/
 * ../Protestant churches/

Chapter 5: Prophetic Movements

 * ../Mormonism/ (1830)
 * ../Adventism/ (1863)
 * ../Christian Science/ (1879)

Chapter 6: Christian doctrine and debates

 * ../The nature of Christ/
 * ../Justification, salvation and grace/
 * ../Other teachings and debates/

Chapter 7: Other religions

 * ../Christianity and the world's religions/
 * Islam
 * Hinduism
 * Buddhism

Return to Biblical Studies/Christianity contents

title: Biblical Studies/Christianity/Overview


text:
Cookbook:Oatmeal Chocolate Chip Cookies I

| North American Cuisines | Cuisine of Ontario | Desserts

The oatmeal chocolate chip cookies recipe here, unlike many other cookie recipes which are manipulations of straight flour-based cookies, was made specifically for use with oats.

Ingredients

 * 2 eggs
 * ⅔ cup (150 g) shortening
 * 1 cup (240 g) brown sugar
 * 2 tablespoons milk
 * Vanilla extract
 * 1 pinch salt
 * 1 ½ cups (350 g) all-purpose flour
 * 1 teaspoon baking powder
 * ½ teaspoon baking soda
 * 1 teaspoon ground cinnamon
 * 1 cup (240 g) rolled oats
 * ¼ cup (60 g) chocolate chips
 * ¼ cup (60 g) walnuts

Procedure

 * 1) In a large bowl beat eggs lightly to break the yolks, then mix in the shortening—you should have a loose mixture.
 * 2) Mix in the brown sugar, milk, vanilla, and salt.
 * 3) Mix the flour, baking powder, soda, cinnamon, and oatmeal together in another bowl.
 * 4) Mix the wet and dry mixes together to get a soft dough.
 * 5) Stir in chocolate chips and walnuts.
 * 6) Make balls and place onto a greased or parchment-lined baking sheet. Bake in an oven prheated to 180°C (350°F) for 15–20 minutes.

Notes, tips, and variations

 * Experiment with more or fewer chocolate chips and walnuts—tastes may vary.
 * Lightly coat the nuts and chips with flour before adding to the mixture.


text:
Neapolitan/prepositions

 * Note:
 * d' is used before a word beginning with a vowel (d"o, for example), 'e is used before consonants.
 * in usually becomes 'n or 'm before a consonant ('ncielo (in the sky) or 'mmiezo (in the middle), for example)
 * p' is used before a word beginning with a vowel (p"o, for example), pe' is used before consonants.

Prepostions in Neapolitan are not generally articulated as they are in Italian, with the following exceptions:

 * ô = a + 'o (Italian: al, allo) = to the (masculine)
 * â = a + 'a (Italian: alla) = to the (feminine)
 * ê = a + 'e (Italian: ai, agli, alle) = to the (plural)

 * (d)int'ô = in + 'o (Italian: nel, nello) = in the (masculine)
 * (d)int'â = in + 'a (Italian: nella) = in the (feminine)
 * (d)int'ê = in + 'e (Italian: nei, negli, nelle) = (plural)
 * Note that "in the" is not commonly used and usually you only use "in"

 * 'ncopp'ô = ncoppe + 'o (Italian: sullo) = on the (masculine)
 * 'ncopp'â = ncoppe + 'a (Italian: sulla) = on the (feminine)
 * 'ncopp'ê = ncoppe + 'e (Italian: sui, segli, sulle) = on the (plural)

Napoletano/Preposizioni

title: Neapolitan/prepositions


text:
Cookbook:Acesulfame

| Sweeteners

Acesulfame, also called Ace-K among others, is an artificial calorie-free sweetener.

Characteristics
Acesulfame is about 100–200 times sweeter than table sugar, though it can have a bitter aftertaste. It is more heat-stable than some other artificial sweeteners, which allows it to be used in baked goods.

Use
It is used extensively in commercial baked goods, beveragees, candies, puddings, and other low-sugar or -calorie products.

Acesulfame is often combined with other artificial sweeteners like cyclamate, sucralose, and aspartame. This manner of blending not only increases the sweetness but is also known to reduce acesulfame's bitter off-taste.

title: Cookbook:Acesulfame


text:
A-level Mathematics/OCR/C4

This is the Core Mathematics 4 module of the A-level Mathematics book. This module assumes that you are familiar with the ../C1/, ../C2/, and ../C3/ modules. Please post all questions to A-level Mathematics/Discussion.

Contents

 * 1) /Algebra and Graphs/
 * 2) /Advanced Differentiation/
 * 3) /Advanced Integration/
 * 4) /First Order Differential Equations/
 * 5) /Introduction to Vectors/
 * 6) /Formulae/

title: A-level Mathematics/OCR/C4


text:
A-level Mathematics/OCR/FP1

This is the Further Pure Mathematics 1 module of the A-level Mathematics book. This module assumes that you are familiar with the ../C1/ and ../C2/ modules. Please post all questions to A-level Mathematics/Discussion.

Contents

 * 1) /Summation of Series/
 * 2) /Mathematical Induction/
 * 3) /Roots of Polynomial Equations/
 * 4) /Complex Numbers/
 * 5) /Matrices/
 * 6) /Appendix A: Formulae/

title: A-level Mathematics/OCR/FP1


text:
A-level Mathematics/OCR/FP2

This is the Further Pure Mathematics 2 module of the A-level Mathematics book. This module assumes that you are familiar with the modules ../C1/, ../C2/, ../C3/, ../C4/ and ../FP1/. Please post all questions to A-level Mathematics/Discussion.

Contents

 * 1) /Rational Functions and Graphs/
 * 2) /Polar Coordinates/
 * 3) /Hyperbolic Functions/
 * 4) /Complex Differentiation/
 * 5) /Complex Integration/
 * 6) /Numerical Methods/

Formulae
By the end of this module you will be expected to have learnt the following formulae:
 * $$ \cosh x \equiv \frac{1}{2}( e^x + e^{-x} ) $$
 * $$ \sinh x \equiv \frac{1}{2}( e^x - e^{-x} ) $$
 * $$ \tanh x \equiv \frac{\sinh x}{\cosh x} $$

title: A-level Mathematics/OCR/FP2


text:
Visual Basic/Files

Another essential part of Visual Basic is file Input/Output, that is, working with files. While programming, you may want at some point to save data so they may be accessible for further use. This is where file I/O comes in. VB allows us to perform most operations available in Windows Explorer and DOS command line. Before you can do this, you need to understand how file I/O works.

Layout of Data
VB generally arranges data into records and fields for the programmer's convenience. The best way to explain this is by illustrating it: Bob,Larry,George Kevin,Ken,Alec This is obviously data containing names. Each line of data is called a record. So the first record contains Bob, Larry, and George. A field is each item in a record. So the first field in the first record would be Bob, the second field would be Larry, and so on. There may be as many fields and records as you see fit. Records and fields are created really just for the programmer's convenience. For greater flexibility, you can also view the whole thing as a string. And you can split the string into records and fields yourself with the built-in Split function.

Input
When a program receives data from an outside source, it is considered input. In Visual Basic, this source is usually a standard text file, with a .txt file extension(as which could be read with Notepad). First, you need to open the file from which you want to read the data. This is done using the following code: Open For As For example: Open "c:\filename.txt" For Input As #1 The file path can be anything you want, if it doesn't exist, a new file (and directory(s)) will be created. The extension of the file doesn't matter much. It will not affect the content of the file nor the process of writing/reading the file. So you can also do this: Open "c:\filename.myfile" For Input As #1 Or this: Open "c:\filename" For Input As #1 The open and file path are self explanatory. However, "for input" states it is being used to receive data from an outside file, VB is "inputting" data from a file into variables. When outputting(writing to a file), this is changed to "for output". When we want to open a file in binary, it's "for binary". "As #1" is which channel is being used. When you are seeking specific information from the file you would use "for random". A channel could be seen as Visual Basic setting up a pathway to the file. Only one file can be used on a channel at a time. So if you want to open multiple files without closing any, you can use different channels. To input a line of data, it is fairly simply: Input , For example: Input #1, x, y, z This will read data from whatever channel 1 is connected to. It will store the first field of the current record into X, and the second field into Y, and the third into Z. Finally, we should ALWAYS close the file after the work is done. The syntax is simple: Close As an example: Close #1 More on using input will be covered in the "Use of Data" section.

Note: If the code will be part of a larger program, the channel number should be obtained in a dynamic way instead of a hard-coded number. This is done using the function FreeFile Dim nLogFile As Long nLogFile = FreeFile Open "c:\filename" For Input As #nLogFile ...  Close #nLogFile

Output
Output is very similar to input. The only difference is, well, it sends information OUT of the program and into a file. Once again, we shall only use text files (.txt). First you must open the file: Open "C:\filepath.txt" For Output As #1 You may have noticed, the only thing that differs from opening a file for input, is the "For Output". Once this is done, everything else is simple. Write #1, x, 5 Assuming X = 3, if you open the text document it will look like: 3, 5 You can write any value or variable to a file, however it is important to note that, when writing a string, it should be placed in quotes. If it is a variable containing a string, this is done automatically. Another important note is that two consecutive write statements will write to separate lines. For example: Write #1, 5, 4 Write #1, 7, 4 Write #1, "this is a string" Will appear in the file as 5, 4 7, 4 "this is a string" Keep in mind, when outputting to a file, it will ERASE all prior information in the text. To add on to existed information, the "Append" command must be used.

If you are writing data to a file for use by some other program, you may find that you don't want the quotes that VB puts around your strings. You can avoid writing the quotes by using the Print command instead of the Write command. For example: Print #1, "this is a string" Will appear in the file as this is a string If, during runtime, the file at hand was modified, and a new line was added which contained necessary data, and the open statement ended as "#1", whatever was in line 1 of the file would be written over(only if the file was opened as Output). To solve this, a variable is dimmed as FreeFile (Dim FF as FreeFile). This will open the first free slot or line in the file at hand. The new Open statement would become: Open "C:\filepath.txt" For Output As FF (will erase file) Open "C:\filepath.txt" For Append As FF (will not erase file) Using the second statement, the first free line in the file will be written to.

How to specify the path to a file
In practice it is rare for open statements to look like this:

Open "C:\filepath.txt" For Append As FF

Usually the path to the file will be held in a string variable:

Dim s As String s = "C:\filepath.txt" Open s For Append As FF

The variable, s, simply needs to hold a path to the file. The path can be an absolute path such as:

s = "d:\users\me\my file.txt"

or a file in the current directory (use CurDir to find out what that is):

s = "my file.txt"

or a path relative to the current directory like this:

s = "..\you\your file.txt"

or like this:

s = "mysub\myother file.txt"

For the more adventurous it can also include a reference to a shared file on a server that doesn't use a drive letter:

s = "\\someserver\someshare\somefile.txt"

Examples
An example form using file reading can be found here. Right click 'here' in Internet Explorer and then 'Save Target As...' to save the form file.

Please upload more files with examples. It will be really helpful for the developer.

title: Visual Basic/Files


text:
Visual Basic/Data Types

Data types in Visual Basic can be divided into three groups:

 * Native: Types that are understood directly by the Visual Basic compiler without assistance from the programmer
 * User-defined: commonly referred to by the initials UDT, meaning User defined Type, these correspond to Pascal records or C structs
 * Classes: the basis for object oriented programming in Visual Basic. Classes include forms, add-ins, and database designers.

If you are using Excel VBA, remember that VBA is essentially VB6, and hence those rules apply.

Built in Types
The built in types are:

Byte, Integer & Long
Example:

Now those variables will only be capable of storing integer values (without decimal). Long integers can store a number with a bigger range of value than integers but they occupy a bigger space of RAM.

Some functions you need to know: Int

Int converts a decimal value into an integer value:

Single & Double
These data types can store decimal values. "Double" compared to "Single" is similar to the "Long" compared to "Integer":

Some useful functions: Round

Round rounds off a decimal to a certain number of decimal digits that the programmer wants. The first argument should be a decimal value which you want to round off. The second argument specifies the number of decimal digits you want, for example:

String
A string is an array of characters. As an example:

Strings can be concatenated (connected together to form a new string) using the "&" operator. For example,

A normal string variable occupies 10 bytes of RAM, plus the string's size, and can hold up to 2 billion characters!

Some frequently used built-in string constants: vbTab, vbCrLf

vbTab contains a string that does the same thing as the Tab key on your keyboard, while vbCrLf creates a character return and a line feed(similar to the Enter key):

Will print:

Jack:   1 pie me:     10 pies

To include special characters and quotation marks in the strings, the Chr function may be used:

Some string functions: Str,Val,inStr,Mid,Replace,Trim

In fact there are tons of built-in string manipulation functions available. But right now, I'll just introduce two: Str and Val.

Str converts any numerical value into a string value while Val converts a string value into a numerical value(only when it's convertible).

Even if you don't do the conversion, you will not end up getting Type Mismatch Errors. However, it is considered better to use explicit type conversions, because it is easier to debug.

Even if you do be prepared for next to impossible to debug problems caused by VB refusing to convert something and refusing to tell you what the heck it is. VB is extremely touchy and raises an exception at the least expected times.

Structure
An example definition of a structured type: The type has to be defined outside of a procedure.

A variable of a structure type is not an object.

Links:
 * Type Statement, Office 2013, msdn.microsoft.com
 * Type Statement at Visual Basic for Applications Reference, msdn.microsoft.com

Enumeration
An example definition of an enumerated type:

Links:
 * Enum Statement, Office 2013, msdn.microsoft.com
 * Enum Statement at Visual Basic for Applications Reference, msdn.microsoft.com

Type Test
To find out about the type of a variable, you can use "TypeOf ... Is ..." test. The tested types can only be object types and structure types, but the test can be applied to any variable, whether typed as an integer, a string or an object.

An example of TypeOf in Excel:

An example test with a "Select Case True":

You can further find out about a type using IsObject and TypeName functions:

Links:
 * If...Then...Else Statement at Visual Basic for Applications Reference, msdn.microsoft.com
 * TypeName Function at Visual Basic for Applications Reference, msdn.microsoft.com
 * IsObject Function at Visual Basic for Applications Reference, msdn.microsoft.com
 * IsArray Function at Visual Basic for Applications Reference, msdn.microsoft.com
 * IsDate Function at Visual Basic for Applications Reference, msdn.microsoft.com
 * IsNumeric Function at Visual Basic for Applications Reference, msdn.microsoft.com
 * IsNull Function at Visual Basic for Applications Reference, msdn.microsoft.com

title: Visual Basic/Data Types


text:
Film History/Film noir

"Film Noir" is a term that was applied to a style of American cinema that was popular in the 1930s and 40s. The term translates to "Black Film," which refers to both the characteristic lighting and the dark subject matter. Noir films often depict different aspects of the criminal underworld, and are most commonly set in the 'mean streets' of the city.

Many of the most recognizable early noir films were mysteries involving a hard-boiled detective like Sam Spade (played by Humphrey Bogart) who gets involved with a woman who hires him to delve into the criminal underworld to solve a case. Many of these tales are based on dime-store novels (also known as "pulp fiction") written by authors like Dashell Hammett ("The Maltese Falcon").

Other popular noirs of the period often tell the tale of an average joe who is put into a difficult situation that continues to get worse, pushing him to his ethical, mental, physical, or moral limits. Noir is most distinguished by its effective interplay of light and shadow. Noirs are lit very darkly, with beams of light being used to highlight certain important elements of the scene, actors, or action. For example, a hero character would be well-lit, while the villain lurked in the shadows. Someone who was of a questionable nature could pass in between the light and shadow, perhaps with a diagonal shadow hiding their eyes while the rest of their body is well-lit.

One of the biggest requirements for a noir was the presence of the femme-fatale character. This was often a very beautiful woman, attractively dressed, who seduced the hero into her world of darkness like a black widow spider. She could be the detective's client, the gypsy who knows a little too much, the girlfriend or wife of the protagonist, or commonly the villain in the story.

Noir films continue to be made today, but purists often dub them "neo-noir," saving the term "film noir" for the period of films between the 1930s and 1950s. Some popular examples of neo-noir are: Chinatown, The Two Jakes, The Grifters, Blood Simple, Fargo, Pulp Fiction, L.A. Confidential, The Man Who Knew Too Much, Body Heat, Devil in a Blue Dress and Sin City. Some popular directors of neo-noir are: the Coen Brothers, Quentin Tarantino, Robert Rodriguez, and David Lynch.

title: Film History/Film noir


text:
User:TokenScott

Just a friendly guy who knows how to write fairly well and loves to learn as much as he can about almost any topic.

I started the film noir page in the film history book before obtaining an account here, and wrote it very late at night off the top of my head. I will continue to flesh it out using the notes I took in my Film Noir class at Otis College of Art and Design in the spring of 2002.

title: User:TokenScott


text:
Visual Basic/Object Oriented Programming

We will now move into a more advanced aspect of VB - OOP. But don't worry, Object Oriented Programming is quite simple, in fact it is probably simpler for those who have never programmed before than for those with long experience of traditional Fortran/Basic/Pascal (pick your favourite imperative language).

You should be familiar with VB's event-driven programming style by now. However I'll explain it again. When you're doing general VB programming, your thoughts should go in this pattern: "If the user does this, what should happen? How would I make it happen?" Then you would write the program to fit the answers to these questions. That is event-driven programming. You program according to what events the user would trigger. Dragging a picture, clicking a button, and typing a word are all events.

You, being the brave coder that you are, would ask: "WHY do I HAVE to think like that??"

Well here's an alternative way for you to think: Object Oriented Programming(OOP). In the world of OOP, you break a problem down into small parts and solve them individually. If you are to program in an object oriented style, you would think of every variable or functions as a property of an object, and everything would seem like an object to you. OOP is hard to explain so you'll have to experience it in the following examples.

Imagine that you have a bottle of juice. What properties does it have? What events does it have?(What can it do?) Here's a list I could think of:

Behold. That's our first class. Don't worry about anything right now. I will go over those later. Anyway, let's assume that this class is named, "Juice". Think of it as a general description of a bottle of juice. Now we can create an actual bottle of apple juice:

Watch:

"Wait", you interrupted my rant once again, "but why do I have to use OOP? Just because you hate apple juice?"

OOP is good for large-scale programming - As your code grows large, there are going to be more and more procedures/functions to your program, and your code is going to be so cluttered that one more look at it, you'd scream. That is why I'm teaching you OOP! (So instead of looking at hundreds of scattered procedures/functions, you look at organized Objects.)

Types
You can think of a type as a simple form of class. Types can only hold variables, not procedures/functions.

An important distinction between user defined types ('UDT') and 'classes' in 'VB6' is that 'UDTs' are value types while 'classes' are reference types. This means that when you store an object ('instance' of a 'class') in a variable what actually happens is that a pointer to the existing object is stored but when you store a 'UDT' instance in a variable a copy of the instance is stored. For instance imagine that you have defined a class, 'Class1', and a UDT, 'Type1':

Now assign ac to bc:

and at to bt

Now make a change to one of the properties of bc and look at the corresponding property in ac. You should see that when you change bc that ac also changes. This is because ac and bc are really pointers to the same block of memory. If you do the same exercise with bt and at you should see that changing properties of bt does not affect at. This is because at and bt are values not references and occupy distinct locations in memory.

This is important when storing objects in 'Collections'. If you add an object to a collection you can later change the values of its properties and the object in the collection will also seem to change. in fact it is the same object because what is stored in the collection is the reference ('pointer') to the object. However if you store a 'UDT' in a collection what is stored is a copy of the values not a reference so changing the original UDT will not affect the content of the Collection.

Classes
Classes are a combination of subroutines and types. By that I mean that when you write a class it looks very much like a type but is also contains subroutines and functions.

Each class in VB6 is a distinct file, there can only be one class in a file and the class cannot be spread out in several files; this is a feature of VB6 not a requirement of object oriented programming.

A class looks very much like an ordinary module but has the file extension .cls instead of .bas

Inheritance
There are two types of inheritance: implementation and interface. However Visual Basic Classic provides only Interface inheritance. Implementation inheritance can be simulated by a combination of interface inheritance and delegation.

One of the common ways to introduce inheritance is to show a program that creates dog and cat objects or car and train objects.

For example in Visual Basic we can declare two classes dog and cat like this:

module main
When you run this program it will print:

Woof Meow

Now this is all very well until you decide that you would like an array of pets:

Unless you declare the aPets array as variant you have to give it a type. One way is to create a class called cPet and use it instead of cDog and cCat:

Class cPet
Now our main routine might look like this:

This should print:

Woof Woof Woof Woof Woof Meow Meow Meow Meow Meow

Look reasonable? For the requirements so far revealed this works fine. But what happens when you discover that there are things that cats do that have no analogue in dogs? What about other kinds of pet? For example, you want your cat to purr. You can have a method called purr but where will you put it? It surely doesn't belong in cPet because dogs can't purr and neither can guinea pigs or fish.

The thing to do is to separate out those features that are common to all pets and create a class that deals only with those, we can rewrite cPet for this purpose. Now we can go back to our original cDog and cCat classes and modify them to inherit the interface from cPet.

Class cPet rewritten
Notice that the Sound method is empty. this is because it exists only to define the interface. The interface is like the layout of the pins on a plug or socket; any plug that has the same layout, size and shape will plug in to a socket implementing the same interface. What goes on inside the thing you plug in is a separate issue; vacuum cleaners and television sets both use the same mains plug.

To make this work we must now modify cDog and cCat:

Collections
In the pet examples above an array of cPet objects is used to hold the pets. This works well if you know exactly how many pets you have. But what happens if you adopt another stray puppy or your cat has kittens?

One solution is to use a Collection object instead of an array. A collection object looks a little like an array but lets you add and remove items without worrying about the declared size, it just expands and contracts automatically.


text:
Visual Basic/Effective Programming

When programming effectively in any computer language, whether it is VB or C++ for example, there should be consistency to your style, it should be organized, and should aim to be as efficient as possible in terms of speed of execution and use of resources (such as memory or network traffic). With established programming techniques, errors can be reduced to a minimum and be more easily recognized, and it will make the job of the programmer much easier and more enjoyable.

There are many different aspects to writing reliable programs. For a short program used interactively and only by the author it can be reasonable to break all the rules in the service of quickly getting the answer. However, if that little programs grows into a large program you will end up wishing that you had started on the right path. Each programming language has its strengths and weaknesses and a technique that assists in writing good programs in one might be unnecessary, impossible or counterproductive in another; what is presented here applies to VB6 in particular but much of it is standard stuff that applies or is enforced in Pascal, C, Java and other similar imperative languages.

General Guidelines
These suggestions will be described in greater detail further below. None of these can be called rules and some are controversial, you have to make up your own mind based on the costs and benefits

 * Write comments that explain why you do what you do. If the code or the problem being solved is especially complex you should also explain why you chose the method you did instead of some other more obvious method.

 * Indent your code. This can make reading the code for others easier and makes it easy to spot where statements have not been closed off properly. This is especially important in multiply nested statements.

 * Declare all variables, enforce this by placing Option Explicit at the top of every code module,

 * Use meaningful variable and sub routine names. The variable FileHandle means a lot more to us humans than X. Also avoid the tendency of abbreviating names as this can also make it hard to read code. Don't use FilHan where FileHandle would be clearer,

 * In the argument list of functions and subs declare all arguments as ByRef. This forces the compiler to check the datatypes of the variables you pass in,

 * Declare variables, subs, and functions in the smallest possible scope: prefer Private over Friend and Friend over Public.

 * Have as few variables as possible declared Public in .bas modules; such variables are public to the whole component or program.

 * Group related functions and subs together in a module, create a new module for unrelated routines,

 * If a group of variables and procedures are closely related consider creating a class to encapsulate them together,

 * Include assertions in the code to ensure that routines are given correct data and return correct data,
 * Write and execute tests,

 * Make the program work first and work fast afterwards

 * Where a variable can hold a limited range of discrete values that are known at compile time use an enumerated type,

 * Break large programs into separate components (DLLs or class libraries) so that you can reduce the visibility of data and routines, to just those other pieces of code that need to use them,

 * Use a simple prefix notation to show the type of variables and the scope of routines.

Declaring variables
Earlier in this book, you may have been taught to declare variables with a simple Dim statement, or not at all. Declaring variables on different levels is a crucial skill. Think of your program as three branches: The module (open to all forms), individual forms, and the sub programs themselves. If you declare a variable in your module, the variable will retain its value through all forms. A dim statement will work, but it is tradition to use "Public" in its place. For example:

Declaring something at the top of your form code will make it private to that form, therefore, if you have X=10 in one form, and X=20 in another, they will not interfere. If the variable was declared public, then there would be interactions between the values. To declare something in your form, it is traditional to use "Private".

And finally, there are the subprograms. Dimensioning variables only to a subprogram is highly effective, this way you can use default variables (such as sum for sums) in all subs without the need to worry about one value changing because of another section of code. There is, however, a twist. Dim, what you are accustomed to, will not retain the value of the variable after the sub is done. So after rerunning the sub, all the local variables in the sub will be reset. To get around this, a "Static" may be used.

Some of you may want to take the easy way out, and just use Public on everything. However, it is best to declare something on the smallest level possible. Generally arguments are the best way to send variables from one sub to the other. This is because arguments make it far easier to track exactly where variables are being changed in case of a logic error, and almost limits the amount of damage a bad section of code can do. Declaring variables is, again, useful when using default variables. Common default variables are:

I for loops J for loops Sum(self explanatory) X for anything

So, rather then making variables I and II or Sum1,Sum2, you can see why keeping variables local is a useful skill.

Comments
Every programmer I know dislikes writing comments. I don't mean just illiterate script-kiddies writing some brain dead Visual Basic Script to delete all the files from some poor grandmother's PC, I mean them and everyone up to people with multiple Ph.D.s and honorary doctorates.

So if you find it difficult to convince yourself that comments are a good idea you are in good company.

Unfortunately this isn't a case of you and I being as good as them but of them being as bad as us. Good comments can be critical to the longevity of a program; if a maintenance programmer can't understand how your code was supposed to work he might have to rewrite it. If he does that he will also have to write more comments and more tests. He will almost certainly introduce more bugs and it will be your fault because you didn't have the courtesy to explain why your program was written the way it was. Maintenance programmers are often not part of the original team so they don't have any shared background to help them understand, they just have a bug report, the code and a deadline. If you don't write the comments you can be sure that no one will add them later.

Comments need to be written with the same care and attention as the code itself. Sloppily written comments that simply repeat what the code says are a waste of time, better to say nothing at all. The same goes for comments that contradict the code; what is the reader meant to believe, the code or the comment. If the comment contradicts the code someone might 'fix' the code only to find that it was actually the comment that was broken.

Here are some example comments:

That comes from one of my own programs that I created by hacking at a template provided by someone else. Why he added the comment is beyond me, it adds nothing to the code which contains the word CommandBar twice anyway!

Here is another from a similar program:

Same degree of pointlessness. Both examples are from programs that I use everyday.

Another from the same program which shows both a good comment and a pointless one:

The first comment line simply repeats the information contained in the name, the last comment line tells us only what we can easily glean from the declaration. The middle two lines say something useful, they explain the otherwise puzzling use of the Variant data type. My recommendation is to delete the first and last comment lines, not because they are incorrect but because they are pointless and make it harder to see the comment that actually matters.

To summarize: good comments explain why not what. They tell the reader what the code cannot.

You can see what is happening by reading the code but it is very often hard or impossible to see why the code is written as it is.

Comments that paraphrase the code do have a place. If the algorithm is complex or sophisticated you might need to precis it in plain human language. For example the routines that implement an equation solver need to be accompanied by a description of the mathematical method employed, perhaps with references to textbooks. Each individual line of code might be perfectly clear but the overall plan might still be obscure; a precis in simple human language can make it plain.

If you make use of a feature of VB that you know is little used you might need to point out why it works to prevent well-meaning maintenance programmers cleaning it up.

If your code is solving a complex problem or is heavily optimized for speed it will need more and better comments than otherwise but even simple code needs comments that explain why it exists and outlines what it does. Very often it is better to put a narrative at the head of a file instead of comments on individual code lines. The reader can then read the summary instead of the code.

Summary

 * Comments should add clarity and meaning,
 * Keep the comments short unless the complexity of the code warrants a narrative description,
 * Add comments to the head of each file to explain why it exists and how to use it,
 * Comment each function, subroutine and property to explain any oddities such as the use of the Object or Variant data types.
 * If a function has side effects explain what they are,
 * If the routine is only applicable to a certain range of inputs then say so and indicate what happens if the caller supplies something unexpected.

Exercises

 * Take a piece of code written by someone else and try to understand how it works without reading the comments.
 * Try to find some code that doesn't need any comments. Explain why it doesn't need them. Does such a thing exist?
 * Search the web, your own code or a colleague's code to find examples of good comments.
 * Put yourself in the position of a maintenance programmer called in to fix a bug in a difficult piece of your own code. Add comments or rewrite the existing comments to make the job easier.

Avoid Defensive Programming, Fail Fast Instead
By defensive programming I mean the habit of writing code that attempts to compensate for some failure in the data, of writing code that assumes that callers might provide data that doesn't conform to the contract between caller and subroutine and that the subroutine must somehow cope with it.

It is common to see properties written like this:

The reason it is written like this is probably that the programmer of the class in which it sits is afraid that the author of the code that uses it will forget to initialize the object properly. So he or she provides a default value.

The problem is that the programmer of the MaxSlots property has no way of knowing how many slots that the client code will need. If the client code doesn't set MaxSlots it will probably either fail or, worse, misbehave. It is much better to write the code like this:

Now when client code calls MaxSlots Get before calling MaxSlots Let an error will be raised. It now becomes the responsibility of the client code to fix the problem or pass on the error. In any case the failure will be noticed sooner than if we provide a default value.

Another way of viewing the distinction between Defensive Programming and Fail Fast is to see Fail Fast as strict implementation of a contract and Defensive Programming as forgiving. It can be, and is often, debated whether being forgiving is good always a good idea in human society but within a computer program it simply means that you don't trust all parts of the program to abide by the specification of the program. In this case you need to fix the specification not forgive transgressions of it.

Exercises

 * Take a working non-trivial program and search the code for defensive programming,
 * Rewrite the code to make it fail fast instead,
 * Run the program again and see if it fails,
 * Fix the client part of the program to eliminate the failure.

Assertions and Design By Contract
An assertion is a statement that asserts that something is true. In VB6 you add assertions like this:

If the statement is true then the program continues as if nothing happened but if it is not then the program will stop at that line. Unfortunately VB6 has a particularly weak form of assertions, they are only executed when the code is running in the debugger. This means that they have no effect at all in the compiled program. Don't let this stop you from using them, after all this is a feature that doesn't exist at all in many common programming languages.

If you really need the assertions to be tested in the compiled program you can do something like this:

Now the program will stop at the failure when in the IDE and raise an error when running compiled. If you plan to use this technique in more than a few places it would make sense to declare a subroutine to do it so as to reduce clutter:

then instead of writing Debug.Assert you write:

Assertions can be used to implement a form of design by contract. Add assertions at the beginning of each routine that assert something about the values of the arguments to the routine and about the values of any relevant module or global variables. For instance a routine that takes a single integer argument that must be greater than zero would have an assertion of the same form as the one shown above. If it is called with a zero argument the program will halt on the line with the assertion. You can also add assertions at the exit of the routine that specify the allowed values of the return value or any side effects.

Assertions differ from explicit validation in that they do not raise errors or allow for the program to take action if the assertion fails. This is not necessarily a weakness of the assertion concept, it is central to the different ways that assertions and validation checks are used.

Assertions are used to do several things:
 * They specify the contract that must be followed by the calling and called code,
 * They assist in debugging by halting execution at the earliest point at which it is known that something is wrong. Correctly written assertions catch errors long before they cause the program to blow up.

Assertions generally assist in finding logic errors during the development of a program, validation, on the other hand, is usually intended to trap poor input either from a human being or other external unreliable source. Programs are generally written so that input that fails validation does not cause the program to fail, instead the validation error is reported to a higher authority and corrective action taken. If an assertion fails it normally means that two internal parts of the program failed to agree on the terms of the contract that both were expected to comply with. If the calling routine sends a negative number where a positive one is expected and that number is not provided by the user no amount of validation will allow the program to recover so raising an error is pointless. In languages such as C failed assertions cause the program to halt and emit a stack trace but VB simply stops when running in the IDE. In VB assertions have no effect in compiled code.

Combined with comprehensive tests, assertions are a great aid to writing correct programs. Assertions can also take the place of certain types of comments. Comments that describe the allowed range of values that an argument is allowed to have are better written as assertions because they are then explicit statements in the program that are actually checked. In VB you must exercise the program in the IDE to get the benefit of the assertions, this is a minor inconvenience.

Assertions also help ensure that a program remains correct as new code is added and bugs are fixed. Imagine a subroutine that calculates the equivalent conductance of a radiator due to convection (don't worry if the physics is unfamilar):

Now it so happens, if you know the physics, that conductance is always a non-negative number regardless of the relationship between the temperatures T1 and T2. This function, however, makes the assumption that T1 is always greater than, or equal to, T2. This assumption might be perfectly reasonable for program in question but it is a restriction nonetheless so it should be made part of the contract between this routine and its callers:

It is also a good a idea to assert something about the results of a routine:

In this particular case it looks as if the assertion on the result is worthless because if the precondition is satisfied it is obvious by inspection that the postcondition must also be satisfied. In real life the code between the precondition and postcondition assertions is usually much more complicated and might include a number of calls to functions that are not under the control of the person who created the function. In such cases the postcondition should be specified even if it appears to be a waste of time because it both guards against the introduction of bugs and informs other programmers of the contract that the function is supposed to comply with.

Tests
Tests vary from writing a program and then running it and looking casually at its behaviour to writing a full suite of automated tests first and then writing the program to comply.

Most of us work somewhere in between, usually nearer the first alternative than the second. Tests are frequently regarded as an extra cost but like quality control systems for physical products the supposed cost of quality is often negative because of the increased quality of the product.

You can use tests to define the specification of a function or program by writing the tests first, this is one of the practices of the Extreme Programming method. Then write the program piece by piece until all of the tests pass. For most people this seems like a counsel of perfection and entirely impractical but a certain amount of it will pay off handsomely by helping to make sure that component parts work properly before integration.

A test is usually built as a separate program that uses some of the same source code as the deliverable program. Simply writing another program that can use component parts of the deliverable will often be enough to expose weaknesses in the design.

The smaller the component that is being tested the easier it will be to write a test, however if you test very small pieces you can waste a lot of time writing tests for things that can be easily checked by eye. Automated tests are probably best applied to those parts of the program that are small enough to be extracted from the real program without disruption yet large enough to have some complex behaviour. It's hard to be precise, better to do some testing than none and experience will show you where the effort is best expended in your particular program.

You can also make the tests part of the program itself. For instance, each class could have a test method that returns true the test passes and false otherwise. This has the virtue that every time you compile the real program you compile the tests as well so any changes in the program's interface that will cause the tests to fail are likely to be captured early. Because the tests are inside the program they can also test parts that are inaccessible to external test routines.

Hungarian Notation
Hungarian notation is the name for the prefixes that many programmers add to variable names to denote scope and type. The reason for doing it is to increase the readability of the code by obviating the need to keep referring to the variable declarations in order to determine the type or scope of a variable or function.

Experienced Basic programmers have been familiar with a form of this notation for a very long time because Microsoft Basic's have used suffixes to indicate type (# means Double, & means Long, etc.).

The fine details of the Hungarian Notation used in any given program don't matter very much. The point is to be consistent so that other programmers reading your code will be able to quickly learn the conventions and abide by them. For this reason it is wise to not overdo the notation, if there are too many different prefixes people will forget what the rarely used ones mean and that defeats the purpose. It is better to use a generic prefix that will be remembered than a host of obscure ones that won't.

A recommendation for Hungarian Notation is described in greater detail in the Coding Standards chapter.

Memory and Resource Leaks
You might think that because Visual Basic has no native memory allocation functions that memory leaks would never occur. Unfortunately this is not the case; there are several ways in which a Visual Basic program can leak memory and resources. For small utility programs memory leaks are not a serious problem in Visual Basic because the leak doesn't have a chance to get big enough to threaten other resource users before the program is shut down.

However, it is perfectly reasonable to create servers and daemons in Visual Basic and such programs run for a very long time so even a small leak can eventually bring the operating system to its knees.

In Visual Basic programs the most common cause of memory leaks is circular object references. This problem occurs when two objects have references to each other but no other references to either object exist.

Unfortunately the symptoms of a memory leak are hard to spot in a running program, you might only notice when the operating system starts complaining about a shortage of memory.

Here is an example problem that exhibits the problem:

Class1 is a simple class with no methods and a single Public attribute. Not good programming practice for real programs but sufficient for the illustration. The xProblem subroutine simply creates two instances of Class1 (objects) and links them together. Notice that the oObject1 and oObject2 variables are local to xProblem. This means that when the subroutine completes the to variables will be discarded. When Visual Basic does this it decrements a counter in each object and if this counter goes to zero it executes the Class_Terminate method (if there is one) and then recovers the memory occupied by the object. Unfortunately, in this case the reference counter can never go to zero because each object refers to the other so even though no variable in the program refers to either of the objects they will never be discarded. Any language that uses a simple reference counting scheme for cleaning up object memory will suffer from this problem. Traditional C and Pascal don't have the problem because they don't have garbage collectors at all. Lisp and its relatives generally use some variant of mark and sweep garbage collection which relieves the programmer of the problem at the expense of unpredictable changes in resource load.

To demonstrate that there really is a problem add Initialize and Terminate event handlers to Class1 that simply print a message to the Immediate Window.

If the xProblem routine were working without a leak you would see an equal number of Initialize and Terminate messages.

Exercises

 * Modify xProblem to ensure that both objects are disposed of when it exits (hint: setting a variable to Nothing reduces the reference count of the object it points to).

Avoiding and Dealing with Circular References
There are a number of techniques that can be used to avoid this problem beginning with the obvious one of simply never allowing circular references:

 * Forbid circular references in your programing style guide,
 * Explicitly clean up all references,
 * Provide the functionality by another idiom.

In real programs forbidding circular references is not usually practical because it means giving up the use of such useful data structures as doubly linked lists.

A classic use of circular references parent-child relationships. In such relationships the parent is the master object and owns the child or children. The parent and its children share some common information and because the information is common to all of them it is most natural that it be owned and managed by the parent. When the parent goes out of scope the parent and all the children are supposed to be disposed of. Unfortunately this won't happen in Visual Basic unless you help the process along because in order to have access to the shared information the children must have a reference to the parent. This is a circular reference.

--      --  | parent | --->  | child  | |       | <---  |        |  --       --

In this particular case you can usually avoid the child to parent reference completely by introducing a helper object. If you partition the parent's attributes into two sets: one which contains attributes that only the parent accesses and another that is used by both parent and children you can avoid the circularity by placing all those shared attributes in the helper object. Now both parent and have reference to the helper object and no child needs a reference to the parent.

--      --  | parent | > | child  | |       |       |        |  --       --      |                |      |                |      |   --   |       -> | common | <- --

Notice how all the arrows point away from the parent. This means that when our code releases the last reference to the parent that the reference count will go to zero and that the parent will be disposed of. This,in turn, releases the reference to the child. Now with both parent and child gone there are no references left to the common object so it will be disposed of as well. All the reference counting and disposal takes place automatically as part of Visual Basic's internal behaviour, no code needs to be written to make it happen, you just have to set up the structures correctly.

Note that the parent can have as many children as you like, held in a collection or array of object references for instance.

A common use for this sort of structure occurs when the child needs to combine some information about the parent with some of its own. For instance, if you are modelling some complicated machine and want each part to have a property showing its position. You would like to avoid making this a simple read write property because then you have to explicitly update that property on each object when the machine as a whole moves. Much better to make it a calculated property based on the parent position and some dimensional properties then when the parent is moved all the calculated properties will be correct without running any extra code. Another application is a property that returns a fully qualified path from root object to the child.

Here is a code example:

As it stands that really only works for one level of parent child relations, but often we have an indefinite number of levels, for instance in a disk directory structure.

We can generalise this by recognizing that parents and children can actually be the same class and that the child doesn't care how the parent path is determined so long as it comes from the common object.

Now we can ask any object at any level of the structure for its full path and it will return it without needing a reference to its parent.

Exercises

 * Create a simple program using the cfolder and cCommon classes and show that it works; that is, that it neither leaks memory nor gives the wrong answers for the Path property.

Errors and Exceptions
Before discussing the various kinds of errors we'll show how errors are handled in Visual Basic.

Visual Basic does not have exception classes, instead it has the older system of error codes. While this does make some kinds of programming awkward it really doesn't cause all that much trouble in well written programs. If your program doesn't rely on handling exceptions during normal operations you won't have much use for exception classes anyway.

However if you are part of a team that is creating a large program that consists of a large number of components (COM DLLs) it can be difficult to keep lists of error codes synchronized. One solution is to maintain a master list that is used by everyone in the project, another is to use exception classes after all. See VBCorLib for an implementation in pure VB6 of many of the classes in the mscorlib.dll that provides the basis for programs created for Microsoft's .NET architecture.

There are two statements in Visual Basic that implement the error handling system:

 * On Error Goto
 * Err.Raise

The usual way of dealing with errors is to place an On Error Goto statement at the top of a procedure as follows:

EH is a label at the end of the procedure. Following the label you place code that deals with the error. Here is a typical error handler:

There are several important things to notice about this:

 * There is an Exit Sub statement immediately preceding the error handler label to ensure that when no error occurs the program does not fall into the error handler.
 * The error code is compared to a constant and action taken depending on the result,
 * The last statement re-raises the error in case there was no explicit handler,
 * A resume statement is included to continue execution at the failed statement.

It might be that this is a perfectly useable handler for some procedure but it has some weak points:

 * Use of a literal constant,
 * The catch all Err.Raise statement doesn't provide any useful information, it just passes on the bare error code,
 * Resume re-executes the failed statement.

There is no reason to ever use literal constants in any program. Always declare them either as individual constants or as enumerations. Error codes are best declared as enumerations like this:

When you want a new error code you just add it to the list. The codes will be assigned in increasing order. In fact you really never need to care what the actual number is.

You can declare the built in error codes in the just the same way except that you must explicitly set the values:

Taxonomy of Errors
There are broadly three kinds of errors:

 * Expected:Expected errors occur when the user or other external entity provides data that is clearly invalid. In such cases the user, whether a human or another program, must be informed about the error in the data not about where in the program it was discovered.
 * Failure to abide by the contract:a caller fails to supply valid arguments to a subroutine or a subroutine fails to provide a valid return value.
 * Unexpected:an error occurs that was not predicted by the specification of the program.

Expected errors are not really errors in the program but errors or inconsistencies in the data presented to the program. The program can must request that the user fix the data and retry the operation. In such cases the user has no use for a stack trace or other internal arcana but has a considerable interest in clear and full description of the problem in external terms. The error report should point the user directly at the problem in the data and offer suggestions for fixing it. Don't just say "Invalid Data", say which piece of data is invalid, why it is invalid and what range of values can be accepted.

Contract failures usually indicate logic errors in the code. On the assumption that all the invalid data has been weeded out by the front end the program must work unless the program itself is faulty. See the for more information on this topic.

Unexpected errors are the errors that most programmers concentrate on. In fact they are not terribly common, they only appear so because the contract between the various parts of the program is rarely spelled out. Unexpected errors differ from Expected errors in that the user cannot usually be expected to assist in immediate recovery from unexpected errors. The program then needs to present the user with all the gory details of the internal state of the program at the time that the error was discovered in a form that can easily be transmitted back to the maintainers of the program. A log file is ideal for this purpose. Don't just present the user with a standard message box because there is no practical way to capture the description so that it can be emailed to the maintainers.

Expected Errors
These are errors in the input data. From the point of view of the program they are not exceptions. The program should explicitly check for valid input data and explicitly inform the user when the data is invalid. Such checks belong in user interfaces or other parts of the program that are able to interact directly with the user. If the user interface is unable to perform the checks itself then the lower level components must provide methods that validate the data so that the user interface can make use of them. The method used to notify the user should depend on the severity and immediacy of the error as well as the general method of working with the program. For instance a source code editor can flag syntax errors without disturbing the creative flow of the user by highlighting the offending statements, the user can fix them at leisure. In other cases a modal message box might be the correct means of notification.

Contract Errors
These failures are detected by asserting the truth of the preconditions and postconditions of a procedure either by using the assertion statement or by raising an error if the conditions are not met. Such errors normally indicate faulty program logic and when they occur the report must sufficient information to enable the problem to be replicated. The report can easily be quite explicit about the immediate cause of the failure. When using Visual Basic it is important to remember that Debug.Assert statements are only executed in the IDE so it can be worthwhile raising errors instead in all but the most time critical routines.

Here is a simple, too simple, example of contract assertions:

Visual basic will halt on the assertion of n = 0 so if you run your tests in the IDE you will be taken directly to the spot where the error is discovered.

Unexpected Errors
These are errors that are not caught by either validation of input data nor assertion of the truth of preconditions or postconditions. Like contract errors they indicate faulty logic in the program; of course the logic error can be in the validation of the input data or even in one of the preconditions or postconditions.

These errors need the most thorough report because they are obviously unusual and difficult or they would have been foreseen in the validation and contract checks. Like contract failures the report should be logged to a text file so that it can easily be sent to the maintainers. Unlike the contract failures it won't be easy to tell what information is relevant so err on the safe side by including descriptions of all the arguments to the subroutines in the Err.Raise statements.

title: Visual Basic/Effective Programming