The East Peak Fire

By Brad Steele and Miles Steele
(originally published 8/2013)

Arrival

"You've arrived! I've been waiting all day for you to get here."
Nathanial ran down the hill, arms raised in a great big "hug me" expression. He was running to greet Miles who had just arrived at Spanish Peaks Scout Reservation. Miles was only 14 years old, just old enough to be a counselor-in-training. He wouldn't get paid, but he would get to spend six weeks on the side of a Colorado mountain.
Nathanial had worked several summers at Spanish Peaks Scout Reservation. The counselors all referred to the camp as "Speezer", or SPSR. This year, Nathan invited Miles to come and work with him and the rest of the staff. It was quite an honor as most counselors were recommended by existing ones. Miles had been away at summer camp before, but never for the whole summer. He was looking forward to this adventure, but was also a bit anxious to be on his own for so long. While he was expecting to have an exciting summer he had no idea what kind of adventure he was in for.
The Spanish Peaks are a pair of mountains near Pueblo, Colorado that sit all alone surrounded by high plains, ranches, small towns, and National Parks. The east peak towers well above twelve thousand feet and the west peak over thirteen thousand. The isolation of these peaks makes them tremendous sights from the high plains around them. Lush and green in the middle of an arid scrub and grassland, these mountains feel like an oasis in the middle of a vast desert. The nearest town of Walsenburg is a 30 minute drive down a winding gravel road. This distance helps to isolate the area and make it feel like the wilderness that it is.

Spanish Peaks Scout Reservation

SPSR, sat in a broad, steep valley on the North face of the East Peak. Vertical rock walls known as the Dike Walls jutted up from the ground to frame the western side of the camp. The leaders camped just inside these walls at the highest point of the camp overlooking a sweeping meadow. In the center of this meadow was the medical cabin and set of flag poles just uphill. Off to the east were the kitchen, trading post and handicraft lodge. In the woods to the east of these buildings were several campgrounds that would host more than 150 scouts and leaders at a time in the upcoming weeks. Downslope was a small grass parking lot, and the archery and rifle ranges. While the camp didn't appear large, that was part of the appeal. A great number of campers could be hosted here without much disturbance to the landscape. The camp had an almost mystical appeal, complete with its own legends. The peaks are named for Spaniards that once mined coal in the mountain and enslaved the local tribe. As the legend goes there was once a great landslide leaving a huge bowl impression near the peak. This landslide killed the Spaniards and many of the Native Americans. Both the Spaniards and the Native Americans are remembered at sunset and dawn as the profile of a miner fills the bowl at sunset and the profile of a Native American fills the bowl at sunrise. It was indeed humbling to spend time in the shadow of this great mountain.

The First Week

Miles stored his equipment in his tent and set off to join the others for training. The news of fires concerned Miles little. Several forest fires had erupted in other parts of the state the day after he arrived at camp, but they were distant and no cause for concern at this camp. Walking downslope to the archery range he noticed that the cars in the lot all faced nose-out. Far back in his mind he recalled that parking nose-out allowed cars to leave more quickly if necessary. But it was a fleeting thought and it never came up again the rest of the day.
During the first week, Miles met James and many others who came from all over the state and country. Friendships forged at SPSR can become very strong. James was soon to be married to Nathanial’s sister after meeting at SPSR and spending several summers together as counselors.
Miles helped set up each campsite, learned everything he would need to know to be a good counselor, and went through numerous drills and exercises. In a way, counselors are a lot like flight attendants. They might seem like they are just there having a good time, but they are highly trained and ready for anything that might happen. His first week was rough with three training sessions, late bedtimes, and early mornings, but he made it through and was ready for the campers to arrive.

Campers Arrive

Scout troops started rolling into camp on Sunday morning. Shelly, the Program Director, greeted them as they arrived and one by one, then the counselors met the troops and assigned them to their campsites. Miles and Colin were responsible for one of the troops. Their job was to help the troops get oriented to the camp and take care of them during their session. After a week of training, Miles was ready to get started with the campers.
Miles remembered his training. He had taken as many as three classes a day during his first week. Some taught by Shelly, some taught by other counselors. Luke was one that Miles remembered from his classes. He would see Luke a lot throughout the next few days.

The Smell of Smoke

Wednesday was just like any other day. Miles had spent the day working in the kitchen and had just sat down for dinner. When he was about to eat his first bite, a call came over the speakers for everyone to meet at the flags. He rushed to shove a piece of cake in his mouth and left the rest of his food for later. A few steps to the center of camp and he was standing with the other scouts wondering what was going on.
"What's the deal?" Miles asked his friend Colin.
Colin just nodded at the trees beyond the dike walls on the far side of the leaders' camp. Miles noticed that a tree was on fire! As he watched the tree burn, a truck carrying Miles friend, James, and a handful of other camp leaders roared up the hill around the dike walls. Miles’ gaze followed the truck up the hill only to see that now where only one tree had been burning a moment before, a half-dozen trees were blazing. But what James and the other leaders saw behind the dike wall was hidden from Miles’ view in the camp. This wasn't just a couple of trees burning; it was a full-blown wildfire. Embers were already starting to fall on the camp as James radioed down to sound the evacuation alarm. Sirens blared and everyone went into quick action.

Down the Mountain

All of the campers and staff were told to leave their belongings and meet downhill in the parking lot, but not everyone with a car had their keys. As the staff was taking stock of who had car keys, Luke and Shelly rushed into the administration building to get the camp roster so that everyone could be accounted for before leaving camp. The fire quickly invaded camp. Smoke swept across the valley as embers from the fire began to descend on the leader’s camp, including Miles tent.
As the staff was organizing the drive out, Miles watched as his tent and the rest of the leaders’ camp burned in minutes. More embers fell on other parts of camp and set buildings and tents ablaze including the medical cabin just a few feet from the flag poles that the entire camp had gathered around just a few minutes before.

Can You Drive?

"Can you drive?" asked Luke.
"Yes", said Haden.
Luke shoved keys into Haden’s hand and told him to load the car and go. Miles checked scouts off the list and they all got in.
“I’m Miles” – this was the first time Miles had met Haden. All of the counselors and staff had been busy setting up camp and getting the first session going so it wasn’t odd that they had not met yet.
"The ground looks red like Mars", Miles said as he took one last look before getting in the car. The smoke filling the air turned everything a dirty red color. Miles remembered thinking about why the cars were all pointed nose-out and was very glad they were pointed that way as one car after another full of scouts, leaders, counselors, and staff left the mountain.

At the High School

Less than a half hour after leaving camp, only 45 minutes since the first smell of smoke, nearly all of the campers and staff were in nearby Walsenburg and were directed to the local high school where they would spend the night. One group of scouts, on a trek to the other side of the mountain, was picked up by bus and safely dropped off at the high school as well.
The counselors and staff at SPSR safely and calmly evacuated more than 200 people, some as young as ten years old, off of a burning mountain in less than an hour. Scouts train for emergencies just like this, but most scouts never have to face danger. These scouts had to use their training. They executed it well and with precision.
The next morning at dawn these scouts even raised a flag amid the chaos around them and said their oath and law for all to hear under the shadow of the smoke-cloud hanging overhead. Even though the camp was nearly destroyed, many scouts continued on to work at another camp so that scouts who were planning to spend a week at SPSR would still have a camp to attend. Still others planned to return the next year to help rebuild SPSR.

Pluto-Charon and the New Worlds

New Horizons
Now that New Horizons has blazed by the Pluto-Charon system and sent back so many remarkable pictures of ice mountains, frozen nitrogen seas, globe-spanning chasms, misty valleys and glacial flows I feel it's time to rethink what to call them. I say "them" because the two astronomical bodies in question orbit each other as a pair. And around them orbits a system of smaller bodies known as Nix, Styx, Hydra, and Kerberos. These are not a cluster of random objects wandering around the sun, but an organized system not unlike those of Jupiter and Saturn.

Ice Mountains and Hazy Valleys

Dwarves
The IAU and Neil DeGrasse Tyson have chosen to rename Pluto to be a "Dwarf Planet". That's a nice moniker, but I really don't imagine two of the most geologically dynamic bodies in our solar system to carry a pick-axe while whistling a working tune on their way to the mines. A tag more significant must be applied to these objects.

What is a Planet Anyway?

Artist Rendering of Saturn

The English word "planet" derives from the greek word "planētai" which means "wanderer". It was used specifically as a term to define five celestial objects that didn't follow the stars and weren't the already-named "Sun", "Earth", and "Moon". I suggest we go back to that definition of planet and leave that term to Mercury, Venus, Mars, Jupiter, and Saturn. Nothing else should be called a planet. The Sun, Moon, and Earth would get the unique definition of their own names befitting their very special places in our lives.

Names New and Old
So where does that leave the remaining celestial bodies, discovered and undiscovered, in our solar system? I suggest four groups for the remaining objects: these groups would be known as "comets", "asteroids", "moons", and "worlds".

Comets
Comets are easy. They would still remain the celestial objects that exhibit both a parabolic orbit around the Sun and at least some point in their travels vent a tail.

Moons
Moons aren't too difficult either. They would be all of the bodies that orbit a "planet" or "world". Charon doesn't count as a moon because the center of orbit is between it and Pluto. Titan - a much larger body is still a moon because it's center of orbit is within the diameter of Saturn, which is one of our familiar planets. But what is a "world"?

Asteroids or Worlds?

Ceres

Now we get to the more challenging objects. What is the difference between a "world" and an "asteroid"? Traditionally, every body that orbits the Sun between Mars and Jupiter has been called an Asteroid. That might be acceptable, but there are many other objects already discovered outside of that band that we also call "asteroids". I suggest every object in an elliptical orbit around the Sun that doesn't meet any other criteria be called an asteroid.



Worlds
There are, however, still quite a few objects that orbit the Sun in an elliptical orbit that I would not call an asteroid. In my opinion, the decision is easy. For me, any object that is large enough and dense enough to form a nearly spherical shape and orbits the Sun in an ellipse should be called a "World". This would include, but not be limited to, Ceres, Uranus, Neptune, Pluto, Charon, and Eris.

Pluto-Charon Rise Again

Artist Rendering of Pluto-Charon

If we follow this logic then our solar system would be composed of the Sun, Earth, Moon, the Planets, the Worlds, the Moons, the Asteroids, and the Comets. The planets would be as they originally were defined: Mercury, Venus, Mars, Jupiter, and Saturn. The worlds of Ceres, Uranus, Neptune, Pluto, Charon, and Eris (there are other unnamed and undiscovered Kuiper Belt Objects that would also be "worlds" once named) would round out the remaining larger objects. And the rest of the solar system would be made up of countless named and unnamed moons, comets, and asteroids.

New Language
This proposed nomenclature would allow us to use phrases such as "tomorrow morning all of the planets will be visible at the same time", "we've discovered a new world", and "Ceres is the only world in the asteroid belt" without the need to apply validations and exceptions. This grouping would make understanding the organization of our solar system simple and any new discovery would be easily cataloged with no argument or disagreement. Pluto and Charon are no more "dwarves" or "objects" than Mars and Earth. They deserve to be called "worlds".

Teddy Ruxpin and the Uncanny Valley

In 1970, Masahiro Mori proposed a concept in the Japanese journal, "Energy" called the "Uncanny Valley". Read his essay at (http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=6213238). In short, when a humanoid figure approaches the likeness of a living healthy person, our affinity toward this object increases. But once that likeness gets nearly, but not entirely human we become repulsed towards it.

His concept was specific to robotics, but raised questions about our own psychology. What is it that makes us uncomfortable about a situation? In the case of humanoid figures, Mori implies corpses and zombies make us most uncomfortable. Both are very close in appearance and in the case of zombies, behavior, to a healthy real living person. I would personally put celebrity impersonators in the deepest part of the uncanny valley as well.

But what about other situations? Do uncanny valleys exist for environmental experiences? Imagine your feelings about your surroundings based on how similar to nature they might be. Architects often incorporate plants and trees into large interior spaces. Does this plant life really encourage the feeling of the great outdoors or does it feel artificial?

What about other interactions? Recently I needed customer support for a product. I opened a chat window on the manufacturer's site and started up a conversation with the customer service agent. After a bit of back and forth, I realized that I was interacting with a chatbot.

You might remember the first chatbot, Eliza. She is still around, and you too can have a very frustrating conversation with her at (http://psych.fullerton.edu/mbirnbaum/psych101/Eliza.htm).
Today we all regularly interact on a daily basis with chatbots known by names like Siri, Galaxy, Google, and Cortana. We also interact with chatbots without our immediate knowledge just like the one I desperately needed for customer service.

Once I realized that I was dealing with a chatbot I immediately knew I was not going to get what I needed. I proceeded to write down the phone number of the offshore support line and asked the chatbot one more question before signing off, "Tell me about the man eating chicken". After a long processor-intensive pause, my bot-friend could only respond that it didn't know anything about the man eating chicken. Feel free to ask this question any time you are suspicious that you aren't conversing with a human. You can sometimes get very interesting results.

How did I know that I was talking to a machine and not a human being? This bot was following the exact form of question-and-answer interaction that a real human tier-one support agent would follow. In fact, it was surprisingly similar to a real human, but not quite. I knew because I felt like something wasn't right. This chatbot might not have been quite as creepy as a zombie, but it wasn't quite human - and I could tell.

It might be more comfortable to make it clearly obvious that a user's interaction is with a chatbot than to try to get close to a true conversation simulation only to fall into the uncanny valley and turn that user away. I know I was certainly turned away from this chatbot. Had I been using a wizard-style form I would have been more likely to at least get to the end of the interaction. In that case I would know up front that I wasn't dealing with a person, and wouldn't be put-off mid-way through.

Consider what made HAL, from the movie "2001:A Space Odyssey", so unsettling. Besides "his" rampant paranoia and homicidal rampage, HAL was just slightly off. Uncomfortable delays in response, questions asked at peculiar times, and an always-pleasant voice all gave away that HAL might seem human, but missed by just a little. HAL dropped right into the uncanny valley and every audience member knew it from the start. No explanation or set-up was required - we all felt immediately uncomfortable with that pleasant, unceasing, red light.

When designing a customer experience, pay attention to the risk of falling into the uncanny valley. If your interaction can't be completely believable, you might want to go for the unbelievable. Most Teddy Ruxpin dolls (https://www.youtube.com/watch?v=8EshrR-xk2E) either ended up in the closet behind other toys with its batteries removed or in the trash heap. But my niece still has her grandmother's Gunde bear and she will likely pass it on. A Gunde bear is hardly realistic, but it lasts, in part, because it isn't trying to fake it.

Teddy Ruxpin dolls are just creepy. Maybe they belong with corpses, zombies, and celebrity impersonators.

Don't try to fake your customer experience either and everyone will be more comfortable in the end. Avoid the uncanny valley. Make it real or blatantly unreal.

Mr. Turtle, how old are you?

.pendown()

If you’re as old as me then you may remember the term “Turtle Graphics.” You may not. The term is actually even older than me. Turtle graphics was a concept of imagining a turtle walking around on a piece of paper with a pen taped to its back. As it walks around, it drags the pen. Periodically it might walk on tiptoe so the pen doesn’t draw (penup). Eventually the concepts of “MoveTo” and “LineTo” evolved from the idea.

I can recall that Turtle Graphics was a library available to Pascal programmers as long ago as 1980. The developers of Windows API and Mac API adopted the concept and conveniently dropped the turtle reference, pretending (perhaps) that they came up with the idea all on their own. Fast-forward to this day and you’ll find the exact same concept embedded in the “Canvas” tag in HTML5. The turtle lives on!

HTML5 offers two somewhat competing methods for drawing graphics. The “Canvas,” with turtles walking all over it, and scalable vector graphics (SVG). Each has its place and purpose. Interestingly, even SVG has a long history. You’ll see it in nearly identical form within other architectures including Windows Presentation Foundation, but it too is much older than both.

Why should you care?

For the same reasons that you should be sure to read the great novels and the newspaper: Reference. By knowing the history of the tools you use, you will begin to see the relationships between them. Ultimately new concepts will look very familiar, and become much easier to learn. Understanding how everything fits together will also help you innovate and create your own new ideas that may one day outlive the Turtle itself.

For more about how the turtle lives on in Python, see https://docs.python.org/2/library/turtle.html

.penup()

Click, Wait...What?

I was recently flabbergasted by an ATM. I tried to get my money, but had a terrible time and finally gave up. I really should check my balance to be sure I didn't accidentally leave $300 in the dispenser.

This particular ATM had both a broken speaker and what must have been a TI-99/4 computer inside (check out http://oldcomputers.net/ti994.html if you're younger than 40). All of the user interaction was on the screen, and only on the screen. There were no physical buttons of any kind. With the ATM having a dead speaker, I received no audible feedback that it ever received my input. To make matters worse, not only was there no visual response to my finger banging desperately on the screen, but the ATM took a solid second to actually do what I pointed out. So I would hit a number, wait for something to happen and then hit it again. I never was able to get my PIN in the right way. Eventually I just quit trying and walked away.

What happened? I had a bad user experience.

While most ATM's provide a very simple click-a-button-and-beep level of feedback, most of the time that's enough when you're trying to get your money. But sometimes, especially when the interfaces are non-physical, we need a little more.

A while back, Google published a working document entitled, "Material Design". Since they've been burning up the versions with one Android release after another, and most Android devices offer a dearth of physical interactions, it seems that Google has learned a little wants to talk about it. While this document is definitely in its early stages it is well worth a read. A little too much of "Material Design" is dedicated specifically to how Google applied the concepts to Android, but the rest of the document is right on the money.

Devices (and web sites) should be ready to inform the user, not just throw down a bunch of color and fancy animations. The concepts in this document reflect the idea that an interface that is not physical must provide feedback to a user that helps them feel like it is physical.

Consider a remote control. You can feel the buttons, they don't move, often they are color-coded, and sometimes they are textured or shaped in a way that implies their function. Touch-screen devices can't do that. Sure, the buttons can be shaped or colored and in a good design they won't move. But you can't feel them. "Material Design" goes to great lengths to explain how you can design user interfaces that encourage the visitor to experience Zen-like connections that leave them feeling like they really did feel the interface.

Feeling like you really felt the interface will leave you with, well...a good feeling and that's a good thing. I really wish that ATM had left me with a good feeling...or at least my money. Maybe the next one I use will have been designed by someone who read and really understood "Material Design". I can only hope.

Take a look at "Material Design" and feel the digital world change before your very eyes...or at least beneath your finger.

Feeling Empty

Yesterday I did something terrible. I worked very hard to categorize, organize, and then empty my email inbox. This morning I booted up my computer and opened my email to see...nothing. I'm not certain how to handle it. I haven't seen an empty inbox since 1994.

What do I do? I know my tasks and am certain of my strategic direction. I have work to complete. But at this very moment I am faced with a blank, white panel full of emptiness. I feel alone; all alone.

And I am afraid.

When will something arrive and nudge me with that oh, so familiar "ba-bong"? What will it contain? Will it be a virus, a newsletter, a Nigerian Prince asking me for money, or something actually important - like work?

If I still owned a clock it would be ticking away like the telltale heart. Ratcheting up my anxiety like that clack-clack-clack of a roller coaster as I approach the top of the first hill, strapped in with no hope of escape. Panic begins to set in as I ponder what will either feel like love's first kiss or a kick in the groin.

I click "refresh" ... still nothing.

Have I lost my connection? Have I been forgotten? What if the weekend hits and my inbox is still empty? I'm not sure I can handle that.

Ba-bong!

Hello Nigerian Prince, thank you for thinking of me. It has truly been too long.

...Finally

One of the most powerful, but misused logical constructs in programming is the exception. Exceptions provide the programmer with an exit strategy in the event of a runtime error. Any section of code that could fail should be wrapped in a "try" block. If an error occurs within that "try" block then an exception is thrown and any code in the subsequent "catch" block will get executed. Conveniently, in most languages that support exception handling, the reason for the failure is also passed into the "catch" block. This allows the programmer to check why the failure occurred and handle it appropriately.
Unfortunately, more often than not, programmers either simply ignore the exception and move on or pass the exception on to the user and exit the program. You will see this on far too many websites. No user should ever be exposed to an exception. In my mind, displaying an exception to a user is the programming equivalent of dropping one's pants.
Most programming languages that support exception handling offer a third optional code block known as "finally". The "finally" code block is always executed after the completion of the "try" or "catch" blocks. I have seen far too much code in my career that contains no "finally" block, but does contain duplicate code in both the "try" and "catch". In extreme cases I have seen complex code within the "catch" block that is highly likely to throw its own exceptions under certain circumstances. Any code within the "catch" block should be as simple as possible.
Consider the following ASP.Net C# console application. This application accepts commmand-line arguments and displays them back to the user. A common command-line structure accepts arguments that begin with a dash character ("-") as options with parameters immediately following. For example, "hello -name Brad" would tell the "hello" application to accept a "name" parameter with the value of "Brad". For web developers this is similar to the querystring.
A console program consumes the arguments in a globally scoped array called "args":

 static void Main(string[] args)

In this intentionally buggy example, we echo back the arguments to the user. If the user passes "-name Brad LiveResponse -color Red" then the program will echo:

 Total number of command line argument values: 5
 Arguments...
  name=Brad
  LiveResponse
  color=Red

But if the user passes "-name Brad LiveResponse -color" then the program will fail with the following output:

 Total number of command line argument values: 4
 Arguments...
  name=Brad
  LiveResponse
 Exception: Index was outside the bounds of the array.

The exception occurs due to the following bad logic:

 for (int i = 0; i < args.Length; i++)
 {
  if (args[i][0] == '-')
  {
   Console.WriteLine("\t" + args[i].Substring(1) + "=" + args[++i]);
  }
  else
  {
   Console.WriteLine("\t" + args[i]);
  }
 }

In this logic we assume that when an argument that begins with a dash character is provided then the user will always be kind and provide a value after it. But if the user passes "-name Brad LiveResponse -color" the line "Console.WriteLine("\t" + args[i].Substring(1) + "=" + args[++i]);" will cause a runtime error as it will be incrementing the loop counter "i" beyond the end of the "args" array expecting a value for the color parameter.
So now we have a program with a runtime error that is easy to produce. Why did I choose to demonstrate this with a console application? Any time you run a console application from the debugger it will simply exit when it is done. A program like this runs so quickly that you may never see it execute. In order to see the program execute you will need to insert logic that causes the program to wait before closing. In this example I added:

 Console.ReadLine();

This forces the program to wait until the user hits the enter key, allowing us to see the output. In this example we will always want to run this line before the program exits whether an exception occurs or not. This is where the "finally" block comes into play. If you were to put that line within the "try" block it will get executed only if there is no error:

 for (int i = 0; i < args.Length; i++)
 {
  if (args[i][0] == '-')
  {
   Console.WriteLine("\t" + args[i].Substring(1) + "=" + args[++i]);
  }
  else
  {
   Console.WriteLine("\t" + args[i]);
  }
 }
 Console.ReadLine();

You could put it inside both the "try" and "catch" blocks:

 Console.WriteLine("Exception: " + ex.Message);
 Console.ReadLine();

But if you do that then you've added the same line of code in two different places. This introduces additional maintenance and quality risk if you ever want to change the "end of program" wait action to something else. Instead, add a "finally" block after the catch. This block of code will get executed whether an exception occurs or not:

 finally
 {
  Console.ReadLine();
 }

Note that the "finally" block will still get executed even if the code in the "try" or "catch" block returns to the calling operation before completion.
Consider another example of an application that opens connections to a database. These connections must be closed. By placing the close methods within your "finally" block you can ensure that the connections don't remain open in the event of an error.
The "finally" block allows you to simplify your program by placing any actions together that must get executed every time, whether there is an error or not.

---

The whole example program follows. If you would like to see it in action, create a C# console application in Visual Studio and replace the program code with this. I intentionally wrote this program with an error in it. Try it out.

• Run it with a variety of command-line options and see how many ways you can break it.
• Move the "Console.Readline();" statement into the "try" or "catch" block to see what happens.
• Add a "throw" statement into your "try" or "catch" to see what happens (hint: a "throw" in the "catch" block produces very interesting results).
• And, for fun, see if you can write a more robust and terse command-line parser and post it in the comments below.

 using System;

 class Program
 {
  static void Main(string[] args)
  {
   try
   {
    Console.WriteLine("Count: {0}\r\nArguments...", args.Length);
    for (int i = 0; i < args.Length; i++)
    {
     if (args[i][0] == '-')
     {
      //If the argument begins with a dash, include its parameter
      // in the output.
      //If the last argument begins with a dash this line will
      // throw an exception.
      Console.WriteLine("\t"+args[i].Substring(1)+"="+args[++i]);
     }
     else
     {
      //Otherwise just write the argument
      Console.WriteLine("\t" + args[i]);
     }
    }
   }
   catch (Exception ex)
   {
    //The above code with throw an exception
    // if the last argument begins with a dash.
    Console.WriteLine("Exception: " + ex.Message);
   }
   finally
   {
    //Whether an exception is thrown or not this line is
    // always executed.
    Console.ReadLine();
   }
  }
 }