Hell and Hot Chocolate

This was my entry in a short story contest held among the denizens of http://bbs.chrismoore.com (affectionately known to the Mooreons that frequent it as The Boardello).  The challenge was to write a story with the title Hell and Hot Chocolate. I won a mug for this. I love that mug.

Hell and Hot Chocolate

by Jeff Yates

It was cold outside and the skies looked ominous, not that I knew what ominous meant at the time, I was only eight.  I probably would have said the skies looked scary back then or maybe, in an attempt to get the right word, called them odorous.  That would've been wrong though, they weren't odorous at all (at least not from this distance), just ominous.  Mum, fearing for the well-being of her children as mothers often do, made sure we wore extra layers before bracing the winter morning.  My sister wore hiking socks, leg warmers and boots with a pink puffer jacket, pink scarf, pink mittens, and a pink bobble hat; her cheeks glowing red against the biting wind.  I wore two pairs of socks, my wellies, jeans, a vest, a t-shirt, a white school shirt, a wool jumper with a rabbit on the front knitted by my Gran, a scarf of random colours knitted by my Gran, a wool duffle coat, and a flat cap that my parents had bought me for my birthday after my Dad got fed up of me stealing his.  We each carried a satchel containing sandwiches, crayons, paper, and a flask of milky hot chocolate.   My sister was like candy floss from the local fairground and I was like a better looking British equivalent of Macaulay Culkin in Home Alone.

It was Sunday morning and my Mum had just dropped me and my sister at the bottom of the church steps.  They were eroded from wind and rain, cracked by freeze and thaw, and harboured frost-covered plants between their old stone blocks.  Their edges were worn smooth from centuries of churchgoers traipsing their way to and from christening, matins, communion, wedding, evensong and funeral services, Easter, harvest and Christmas celebrations, and Sunday School.  That was where we were heading, Sunday School.  Every Sunday morning after the communion service we would go to Sunday school where various volunteers under the guidance of the rector would impart to us the wisdom of the Bible whilst we made Easter cards or painted one of the Disciples.  Usually, we would have been at the service too but this morning my Mum had struggled to wake me and my Dad: me because I was lazy, my Dad because he was hung-over.  So, there we were, at the bottom of the church steps waving to our Mum as the last of the congregation left the church and Mum drove away.

My sister grabbed my arm and dragged me up the icy steps, "Come on, you mong.  Stop staring at the sky, we'll be late!"  She was ten and with her maturity came her sass.  She was a proper well-spoken little madam and I looked up to her even though we were starting to grow apart; me refusing to mature beyond my years and her racing for the finish line of retirement.  I was sure that within a year, she would be married with kids and I would still be pulling the legs off spiders and putting frogs in her bed (though no Nostradamus, some of my predictions did come true, much to my sister's irritation).

*   *   *

“Today, we are going to talk about Heaven and Hell.  Who can tell me what Heaven is?”

Miss Dickle was about eighteen or nineteen.  She was a member of the youth fellowship and she was hung up on God.  I think it had something to do with the bullying she got, or the boys thinking she was a dyke (I didn’t know what that meant, but they didn’t say it like it was a good thing so I guessed it was bad which my Mum confirmed when I called her one), or a bit of both, but whatever it was, my Dad had said she was bothering God for the wrong reasons.  I could not see any signs that God was bothered by her at all, but then I could not see any signs of God full-stop—other than the ones that hopeful believers had built, installed, or written on his behalf—so what did I know?

Bobby Jenkins raised his hand, “My Mum says that sitting on the washing machine during a full-spin cycle is heaven.”

“Yes, thank you, Bobby.  That isn’t quite what I was looking for.  Anyone else?” said Miss Dickle, making a note and slipping it into her pocket while Bobby shrugged like he had given it his best shot, “No?  Well, Heaven is where God lives.”

“But I thought this was God’s house?” said Angela Joyce.  The twenty-strong group of eight year old children nodded in agreement.

“Yes, it is, but God is everywhere.”  Miss Dickle was used to thinking fast.

“So Heaven is everywhere?” said Angela.

“No.  Heaven is where we go when we die, but only if we’ve been good.  Now, who can tell me what Hell is?”

Julie Brent raised her hand, pushing it as high as she could, using her other arm to prevent the first from falling off before she got to answer.

“Yes, Julie.”

“Hell is a really hot place with fire and lava and the Devil where people go when they’re naughty.”

Julie Brent was a know-it-all and she knew it.  I hated her.

“That’s very good, Julie.  To be exact, Hell is the eternal punishment for those who do not believe in Jesus Christ like we do.  The Devil, who is sometimes called Satan or Lucifer, used to be an angel in Heaven but he tried to fight God and was sent to Hell with a third of the angels who are now demons.  Hell is filled with the souls of the damned and if you do something naughty and you don’t say sorry, that’s where you end up.  The Devil roams the Earth looking for souls to devour, separating them from the spiritual light of God and condemning them to eternal damnation.  Temptation is often used by the Devil to lure the weak away from Jesus Christ and God.  So, when you are tempted to do something that you know you shouldn’t, remember what might happen to you.”

We all sat there in silence, too scared to look anywhere but straight at Miss Dickle, whose face looked deadly serious.  I was pretty sure that none of us fully understood everything she just said, but what we did understand was more than enough to petrify us.  I was horrified, even more so when Bobby shit himself and burst into tears; he was sat right next to my flask.

*   *   *

Mum came to collect us at 11:30.  There we were, standing in the slush at the bottom of the Church steps.  My sister was holding the advent candle she had made and grinning from ear to ear as if it was the best thing ever.  I was holding my flask of hot chocolate at arm’s length, unable to believe that Miss Dickle had washed if all off like she insisted.

On the drive home, my sister happily regaled the little bits of gossip she had overheard during her advent candle manufacturing class while I tried not to think about the implications of my “how to scare the shit out of at least one kid” class.   It wasn’t until we got home that Mum took me aside to ask why I appeared so upset (seems I had been sniffling a little on the way home).  So, I told her what happened, word for word, or at least as well as I could remember and when I was finished, she gave me a hug.

“So, you’re worried that you might go to Hell?”

“No,” I said.

“No?”

“Well, I was, but then Bobby pooed on my hot choc’lit.”

“And that stopped you worrying?”

“Well, you always say it might be tempting to drink it before Miss Dickle finished talking but I shouldn’t.  But today I was going to, then Bobby pooed on it.  And now he’s going to Hell.”

“I don’t think that’s very nice, honey.  You can’t send someone to Hell just for pooing their pants.”

“But he didn’t say sorry and Miss Dickle said that if you don’t say sorry after you’ve done something naughty, you go to Hell.”

“Well, I don’t think Miss Dickle explained that very well.  How about I make you a fresh mug of hot chocolate and we’ll talk about this after dinner?”

“Ok,” I smiled and ran off to watch Bugs Bunny with my Dad.

*   *   *

It wasn’t until the following weekend when I returned to Sunday School, that I discovered Bobby had bigger things to worry about than Hell.  After all, why worry about where you’ll end up when you’re dead when you have to spend the rest of your life being called Bobby Poopants, Poobum Bobby, and Bobby Bobby Bumboy (although that last one didn’t really become popular until he came out during high school).  He never lived down the embarrassment of defecating to the point that it oozed from his shorts and I never ever used that flask again.  Angela Joyce became a hard-hitting journalist, probing politicians and celebrities with her unique style of questioning. Julie Brent got ordained and continued to have an answer for everything.  Miss Dickle got a theology degree and after many years as a missionary, she embraced her sexuality and moved in with Julie Brent.

As for me, well, that’s another story altogether.

Crash handling in Silverlight (Part Two)

This post is the second part of a two part series.

Adding a little polish

In part one of this series we learned about the basic out-of-the-box crash handling that a new Silverlight project provides for both in- and out-of-browser applications, we learned how we can catch unhandled exceptions inside our application or let them escape into the browser to be handled by JavaScript (or a bit of both) and we learned that we are at the mercy of the HTML bridge.

What we had was far from fancy; the user would end up with a potentially broken Silverlight application or a blank screen and only some cryptic text in the JavaScript console to explain. This is not how we make friends, but now that we have a foundation, we can look at how to enhance the experience for our quality departments, ourselves and the poor souls that must suffer for our mistakes, our users. However, some simple modifications to our error handler can move the cryptic text out of the console into the page. We can even add some pizzazz and remove most of the cryptic text too. So let's take what we were left with at the end of part one and add a little polish.

In the following example, I've constructed a simple page that gives the user some information and provides a mailto link for sending the details to our QA department. When a crash occurs, the Silverlight application is hidden and the error page is displayed, customized to the specific error code1 and information.

Now, I understand, this is not the most elegant JavaScript in the world, but it works. Here is what your user sees…

Example of what a user will see when the application crashes
Example of what a user will see when the application crashes

…and if the user clicks our mailto link, they'll get something like this…

Example of the auto-generated e-mail incident report
Example of the auto-generated e-mail incident report

The example could be expanded to add additional information such as the URL of the application, the version of Silverlight and the user agent string by just modifying the JavaScript to include that information2. You could even show the same information on the HTML page that you include in the e-mail (in fact, you can go even further than that, just use your imagination…or read on for some suggestions). And yes, a little CSS would help, but I never promised it would be pretty—pretty can come later; I'm aiming for functional and as functional goes for showing that something is non-functional, this is good enough.

A bridge too far

Of course, as we have access to all the wonders of HTML and JavaScript, we could do so much more. For example, we could play a video to entertain the user while we call a web service that sends our error report automatically to our servers and tweets an apology (it's the personal touches that count). However, it doesn't matter how fancy and special we make the crash experience, it is all for nought once the user installs and uses our application out-of-browser or the HTML bridge is disabled. So, what do we do?

Out of the browser and into the app

The simplest way I have found to handle crash reporting in an out-of-browser application (or an application that lacks the HTML bridge) is to throw up a ChildWindow containing the details of the crash and provide no discernible means to dismiss it, thus disabling your application from further use without closing the application. This relies on the Silverlight runtime remaining intact even though your application suffered a problem; however, from my experience, crashes that take out the runtime are rare, especially in applications that have been tested and have well-formed, correct XAML.

Of course, if the runtime is still working, why stop at a ChildWindow? If you have access to the Silverlight runtime, you could do more like call a web service call or use some trusted API3 or COM4 interface. Whatever you try, exercise caution as you don't want your crash handling to crash as well. Keep it simple and it will serve you well.

Conclusions

Whichever route you choose, you should work hard to cater for all the scenarios that might be encountered, that way you will provide the support your user deserves. When deciding on your crash reporting strategy, always consider:

  • What level of network connectivity might be available?
  • Will the application be in- or out-of-browser? Do you support both?
  • Will the application be trusted and therefore have access to COM or Windows APIs?5
  • What Silverlight runtime(s) will you want to support?

  1. If you were paying attention there, you may have noticed that I mentioned the error code. There are many error codes that can be reported by Silverlight. You can use the error code to tailor your report or even consider not reporting a crash at all, but that depends on just how badly your application will react to the error. 

  2. Getting the User Agent string or the site URL are relatively simple, especially when compared with retrieving the Silverlight runtime version from within JavaScript. Thankfully, this was solved already, just visit this blog for details. 

  3. Silveright 5 

  4. Silverlight 4 and up 

  5. Starting in Silverlight 5, both in- and out-of-browser trusted applications are supported. Earlier versions only support trusted applications when out-of-browser. 

Intervention

I’m pulled away.

Can’t stay,

won’t stay.

Won’t make time

for the things that I‘m

supposed to say.

 

The trust is wrong.

Same song,

loose tongue.

Forgotten lines

remind me what shines.

Just sing along.

 

You say we’ve all got it made.

Sunny days just fade away.

No more time to sit and play.

We’ve lost the war to win you over.

 

But you still want your way,

and your hand is fanned so close.

No more moves to fix the dose.

I’ve lost the war and now it’s over.

 

Inside the folds.

Air holes.

Same souls

left to make

one more big mistake.

Reverse the roles.

 

Apathy, truth,

abuse.

No use

thinking or

allowing time for

it to get loose.

 

You say we’ve got it made.

Sunny days just fade away.

No more time to while away.

Yet the war is lost, the war is over.

 

Still, you want your say,

yet your mouth is closed tight;

hiding shadows in the light.

Victims of war, its dark sweeping over.

Crash handling in Silverlight (Part One)

This post is the first part of a two part series.

I love working with Silverlight but once in a while I get it wrong and I, or worse, a user experiences a crash incident. I believe it is important for developers to acknowledge that incidents will occur and to include incident handling and reporting as first class citizens in the software we write. It benefits both us and our users by providing both a graceful degradation of our application and a source of feedback regarding application stability and bugs.

In this and subsequent posts, I want to take a look at the functionality a new Silverlight project includes for handling and reporting incidents, and then build upon it to give us some top notch error handling in our Silverlight applications.

So, let's start with the basics1

Create a new Silverlight application (including a companion ASP.NET web application or website) and you'll get two flavours of error handling: the first reports errors when you're not debugging your application and the second reports errors when you are2. When there is no debugger attached, errors are reported to the DOM via the HTML bridge. This all happens in App.xaml.cs via an event handler for the Application.UnhandledException event, which is subscribed in the class constructor. The event handler checks whether the debugger is attached and if it is not, it sends the error to the DOM via the cunningly-named ReportErrorToDOM method. The comments in Application_UnhandledException explain what is happening. Also, note that the event is being marked as handled, meaning our application won't stop running just because of this pesky exception.

And a quick look at ReportErrorToDOM shows us the HTML bridge is being used to evaluate some JavaScript that will throw an exception inside the hosting browser.

If you try this and you're using a recent browser, it's very likely that you won't even notice anything happened. I put a button on my vanilla application and tied that to a click-event handler that throws an InvalidOperationException exception. Clicking it in IE9 gave me nothing until I pressed F12, viewed the Console in the developer tools and tried again. In some older browsers, a dialog box may appear indicating a scripting error.

Console in IE9 after a crash using basic Silverlight exception handling
Console in IE9 after a crash using basic Silverlight exception handling

I'll leave it as an exercise for you to go and see exactly what this looks like in your browser of choice, but I think we can all agree that with error handling like this our users must surely feel a warm fuzzy glow (especially with our hidden, cryptic error message and an application that continues running, unfettered by the potentially fatal bug lurking within). In fact, if the HTML bridge is disabled3, there isn't even a cryptic error message!

However, you'll be pleased to read that things are almost ever so very slightly better different when we have the debugger attached.

Attaching the debugger

The exception handler we just looked at only reports the error to the DOM when the debugger is not attached (and the HTML bridge is enabled). When the debugger is attached, the handler does nothing at all and the exception goes unhandled by our application. So what happens next?

Well, when an unhandled exception leaves our application, the Silverlight host looks for a JavaScript method assigned to the onError parameter. If there is such a method, it calls that and stops the application. The default handler is defined for us in the auto-generated HTML and ASPX. You can see its assignment in the default HTML and ASPX pages generated for us when we created our Silverlight application.

The default JavaScript handler generates an error similar to the one we get without the debugger, but with a few extra details4. Unfortunately, just like when the debugger isn't attached, disabling the HTML bridge (or running out-of-browser) also disables the error being reported.

Console in IE9 after a crash using basic Silverlight exception handling with debugger attached
Console in IE9 after a crash using basic Silverlight exception handling with debugger attached

The story so far…

In this introduction to Silverlight incident handling we have seen that, out of the box, we get some basic reporting that in a release scenario, will allow the application to continue running and will output a stack trace in the console5 but, when debugging, will stop the application and output a stack trace plus the added bonus of some extra details6.

I think you will agree, this is not a first class system for handling errors. Of course, all is not lost and in the next post we will look at how we can expand this error handling to be more helpful to both us and our users, perhaps even coping without the HTML bridge. That said, if this is all you use, I recommend deleting the code from App.xaml.cs so that the "debugger attached" style handling is used for all scenarios7. At least that way, when your application crashes, the user won't be able to continue using the application in blissful ignorance of whatever dangers lurk beneath.


  1. More detailed information on error handling in Silverlight, can be found here

  2. I am using Visual Studio 2010 Professional SP1 with the Silverlight 4 SDK. All line numbers refer to a vanilla Silverlight project created using New Project in the File menu. 

  3. You can disable the HTML bridge by adding <param name="enableHtmlAccess" value="false" /> to your Silverlight object declaration or by running your application out-of-browser. 

  4. The Category value is only available if the development runtime is installed, but the Code value is provided with all runtimes. It indicates the type of error, which can be looked up here

  5. If we're running in a browser with the HTML bridge enabled. 

  6. If we're running in a browser with the HTML bridge enabled. 

  7. Please don't actually use this as your error handling. Although it is in the most part, better for the user, your application will appear to crash a little more often as the onError handler gets called for more than just unhandled exceptions. 

Firecracker 5K 2011

11th annual Ann Arbor Firecracker 5K banner

This July 4th weekend, we headed downtown for the Firecracker 5K. Congratulations to everyone else who took part, I hope you all achieved your goals. Even though I had completed two other 5K events this year (DXA2 and the Motor City Triathlon as part of a sprint relay team), I had not managed to run the entire 5K distance (3.1 miles) since the Big House Big Heart run in October 2009*, so I had that goal in mind.

The weather was cool and breezy and the course was the same as last year, nice and flat and taking in some of the best parts of downtown Ann Arbor. With coffee helping to keep my eyes open (I'm not fully functional in the morning, especially on holiday weekends), I pinned my bib on, stretched and found my pace marker in the crowd (around 12 minutes , I was hoping).

After setting out a tad fast it was beginning to feel like I had scuppered my chances of finishing without stopping for a lovely stroll. However, with Cardiotrainer's robot voice giving me pace and distance information over the top of my music (streaming on my phone via the fantastic Audiogalaxy) I was able to focus on my goal and just over 30 minutes later, I was insanely sprinting over the finish line.

My time was 34:01.3, a personal best beating my 2009 Big House Big Heart time of 35:54.6 and my 2011 DXA2 time of 37:39.0 (it also totally blows away my time from last year's Firecracker 5K, 46:50.1). My next goal is to break 30 minutes; when and where that will be I don't yet know.

* I injured myself playing soccer with delusions of skill
† Also know as "somewhere near the back"