C

Cover of "Teach Yourself ASP.NET Ajax in 24 Hours"While following the exercises in the book Teach Yourself ASP.NET Ajax in 24 Hours – one of the few books I’ve been able to find on Ajax for ASP.NET 3.5 – I found an error in the “Hour 9” chapter in the example that covers client-side error-handling (it starts on page 137). I’ve reported this error to the publisher and with any luck, they’ll post a corrected version on their support web page for the book.

I’ve done some searching and haven’t found anything covering this error so I thought I’d cover it here. Better still, I’ll also cover the fix, which turns out to be quite simple. If you’ve been trying out the code in the book and wondering why it doesn’t work, relax: at least in this case, it’s not your fault.

In the course of covering the error and how to fix it, I’ll also talk about how ASP.NET handles exceptions raised by asynchronous postbacks and how you can make use of it to make better user interfaces. Even if you don’t have a copy of Teach Yourself ASP.NET Ajax in 24 Hours, you should find this article an interesting introduction to client-side error handling in ASP.NET Ajax.

Unhandled Exceptions and Asynchronous Postbacks

In ASP.NET Ajax, if an exception is raised during an asynchronous postback and isn’t handled on the server side – that is, in the code-behind – it gets passed along to the client side. What happens on the client side depends on which version of ASP.NET you’re using:

  • In ASP.NET Ajax 1.0, the server-side exception object is serialized into JSON. The JSON is sent to the client, which displays the exception’s message property in an alert box.
  • In ASP.NET Ajax for .NET 3.5, the server-side exception is still serialized into JSON and the JSON is still sent to the client. However, instead of displaying the exception’s message property in an alert box – a presumptuous design decision, if you want my opinion – the client throws the exception, which gives you the opportunity to handle it on the client side as you please.

(In this article, I’ll stick to covering ASP.NET Ajax for .NET 3.5.)

This is quite different from most other web application frameworks, where an exception raised as the result of an XMLHttpRequest call to the server results in some kind of “error” page from the server (or a blank page, if you’re suppressing error reporting).

To illustrate this, let’s put together a simple ASP.NET Ajax application. It’s a single page with a single button, that if clicked, throws an exception.

Here’s the code for the page layout. It’s pretty straightforward:

Listing 1: Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

Some notes about the code:

  • The ScriptManager control at the top of the form enables Ajax by ensuring that the JavaScript needed to support ASP.NET Ajax on the client side is downloaded to the browser.
  • The UpdatePanel control determines the controls that trigger asynchronous postbacks and defines the region of the page that can be updated via Ajax.
  • Button1 is the button control that we want to throw an exception when clicked. We’ll set it to call the Button1_OnClick method, which will contain the exception-throwing code.

The code-behind is very simple. In it, we define a single method: the event handler Button1_OnClick, which is called in response when the user clicks Button1. All we want it to do is throw an exception that uniquely identifies itself:

Listing 2: Default.aspx.cs – Code-behind for the page of our very simple example app.

Running with Debugging vs. Running Without Debugging

Listing 1 and 2 give us enough to make our simple app work. It’s time to take it for a spin.

Here’s something that doesn’t get covered in Teach Yourself ASP.NET Ajax in 24 Hours: what happens when you try to run this app with debugging (starting it by hitting F5 in Visual Studio or “Start Debugging” under the “Debug” menu)?

Here’s a screenshot of what happened for me: simple_app_with_debugging

With debugging on, the unhandled exception thrown in Button1_OnClick is caught by the debugger. Normally, this sort of error-catching behaviour is welcome, but in this particular case, it gets in the way of what we’re trying to achieve: having an exception on the server side and passing it along to the user’s browser to handle.

If we run the same app without debugging, we get the effect we want: the exception is raised on the server side, but the server-side part of the application doesn’t halt with an error message. Instead, the client shows the error message.

Here’s a screenshot. Note that the error message includes the string “Click!”, which is the argument in the throw statement the Button1_OnClick event handler. Thanks to this, we can be pretty certain that the error message is the result of our deliberately-thrown exception:

image

Now that we have the exception that we threw on the server side being handled on the client side, let’s do something with it. 

Handling Exceptions Passed from the Server on the Client Side

Let’s do something simple – let’s catch the exception caused by the button click, and instead of having a JavaScript error box pop up, let’s make a couple of changes to the button:

  • Change its text to “This button has been disabled for your safety.”
  • Disable it.

To handle exceptions on the client side, we need to write some client-side JavaScript. Luckily, this is made simple by the number of handy utility classes defined in the scripts downloaded to the client by the ScriptManager component. In this case, we’re going to make use of the Sys.Webforms.PageRequestManager class to deal with the exception because it provides us with the following:

  • The endRequest event, which is raised after an asynchronous postback has completed and control is returned to the browser.
  • The add_endRequest method, which specifies a method to call when the endRequest event is raised.

Here’s the JavaScript, which we’ll put in a file called ErrorHandler.js:

Listing 3: ErrorHandler.js — Client-side error handler for our very simple example app.

The script performs the following:

  • It registers the method EndRequestHandler as the method to call whenever the endRequest event is raised.
  • It defined the method EndRequestHandler, which does the following:
    • If an exception did occur during the asynchronous callback:"
      • The button’s text is changed
      • The button is disabled
      • The error is reported as handled, which allows the application to continue

Now that we have this client-side code, we need to get it to the client. We do this by using the Scripts section of the ScriptManager to send this file to the client. The listing below shows the updated layout code for our simple application. I’ve highlighted the change in the listing below:

Listing 4: Revised Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

The Scripts section of the ScriptManager lets us specify scripts to be sent to the client along with the page, with each script specified in a ScriptReference tag.

When we run the app (remember, without debugging on) with these changes and click the button, here’s what we get:

Button with text "This button has been disabled for your safety"

In a later article, I’ll look at other ways of using client-side error handling in ASP.NET Ajax in .NET 3.5.

The Error in Teach Yourself ASP.NET Ajax in 24 Hours

Here’s the page layout code for the error-handling example in Teach Yourself ASP.NET Ajax in 24 Hours. The code-behind for the page and the client-side JavaScript are fine, it’s this code that has the error. See if you can spot what’s amiss:

Listing 5: Default.aspx — Page layout of client-side error-handling example in Hour 9 of Teach Yourself ASP.NET Ajax in 24 Hours.

Just for kicks, here’s what happens when you click on the button in the app using the code straight from Teach Yourself ASP.NET Ajax in 24 Hours:

Screen capture of resulting error message from original "Teach Yourself ASP.NET Ajax in 24 Hours" application

The mistake is simple: although there is some error-handling client-side JavaScript in the app, it’s not referenced in the ScriptManager tag, which means it’s not sent to the client. Without error-handling code on the client side, the exception is thrown, there’s nothing to catch it and the user is presented with the standard error dialog box.

The fix is equally simple: reference the script in the ScriptManager tag’s Scripts section:

Once that’s done, the program works as promised.

{ 2 comments }

Cover of the "C Sharp Yellow Book"

As a new Microsoftie and programmer returning to C# after a six-year absence, I have a lot of learning and re-learning ahead of me. In preparation for this, I spent the better part of an afternoon in the “Computers” section of my neighbourhood bookstore going through the C# programming books, sorting the gems from the junk. I took the “beginner’s mind” approach and looked at all the books on the shelves, regardless of the skill level they were written for, even the books that devoted whole chapters to basic concepts like looping and branching. At the very least, it would give me an idea of the current state of programming literature was like in the .NET world.

A couple of weeks later, I stumbled across the C# “Yellow Book”. It’s the standard book for first year computer science students at the University of Hull (I know of it thanks to a Black Adder episode) and written by Rob Miles, a Microsoft MVP and lecturer at that university. Each computer science student there is given a free-as-in-beer printed copy of the book, and now anyone can get a free-as-in-beer PDF copy online.

The C# Yellow Book is quite good, and can easily hold its own against some of the commercial C# books I’ve seen, which typically sell for about $35. It’s written in a clear and breezy style, explains it concepts well, has examples that actually work (I tried some out just for kicks) and often goes beyond typical beginners’ books with many asides called “Programmers’ Points” that explain good programming technique. Its 185 pages cover most of the basic C# language — and most of the example code is run in console mode except for the section near the end that covers basic Windows Forms. After finishing this book, you should have enough background material to tackle an intermediate book on C# or introductory books on .NET topics like GUI programming, ASP.NET or even game development for the PC, Xbox 360 and Zune (yeah, really, the Zune) with XNA.

I’d say that Rob has a strong incentive to make the book as good as possible because it’s the basis of a course at his university and because he can get some rather immediate feedback from its readership. If only that was true for a professor of mine back at Crazy Go Nuts University, whose Pascal programming book (it was the eighties) had terrible examples, an incomprehensible presentation and writing style and annual revisions to foil used-book sales and to force each new class to buy the latest edition. Kudos to Rob and the computer science department at Hull for giving away the course textbook for free!

If you’re a starving student looking to learn Windows programming, I’d recommend getting your hands on a copy of Rob Miles’ free-as-in-beer C# “Yellow Book” and pair it with Microsoft’s free-as-in-beer Visual C# 2008 Express Edition. Alas, I can’t point you to any free-as-in-beer computers.

Links

{ 4 comments }

C++ Pointers for Kids

by Joey deVilla on November 22, 2008

Here’s a fun little claymation video showing called Pointer Fun with Binky that explains C++ pointers “to kids”. Why can’t all programming be taught this way?

My favourite phrase of the moment, thanks to this video, is “Magic Wand of Dereferencing”.

[Found via Being Cellfish.]

{ 3 comments }

Salmagundi for Friday, November 7th, 2008

by Joey deVilla on November 7, 2008

Interview with Chris Slemp, MSDN

joey_devilla_chris_slemp

Here’s another video interview featuring Yours Truly at the PDC: it’s with Chris Slemp, Program Manager for the Server and Tools Online group at Microsoft. In the interview, we talk about MSDN and its new social bookmarking feature.

Click here to watch the video.

“Grim Fandango’s” Puzzle Document

grim_fandango_puzzle_document

If you’re looking to get into the mind of a game designer and the design of one of the most highly-regarded computer adventures games, be sure to check out the Grim Fandango Puzzle Document. Tim Schafer, in “a temporary fit of Cake-induced Grim nostalgia,” decided to put the game’s puzzle design document online in PDF form (it’s 2.3MB in size).

Here’s a great summary of the Grim Fandango Puzzle Document, written by Andy Geers:

I use that word "crafted" because that’s exactly what this newly released document shows: true craftsmanship. We see the incredible attention to detail, the pacing of the narrative as it builds and as the puzzles get increasingly sophisticated, always coaxing the player along with them. As somebody whose spent the last few years trying to write my own adventure game, what struck me most about this document is the sheer simplicity of it – it’s well established that it takes a great deal of clarity and hard work to boil down something so vast as Grim Fandango into such a simple representation that conveys so much information in such a succinct way.

It’s a considerably more interesting read than most specs.

My Job-Related Reading List

Nothing gives you that frozen-caveman-thawed-in-modern-times feeling like returning to a software platform after not developing in it in seven years. Getting back into the swing of Microsoft’s development tools has been fun so far, but it is, as a lot of people have told me, like drinking from the firehose.

reading_list_nov_2008

To quickly get acclimated with C#, ASP.NET and XNA, I’m expensing the following books I bought today:

I’ll let you know what I think of these books as I read them.

“Zero Punctuation” Reviews

And finally, a couple of reviews from my all-time favourite game reviewer, Ben “Yahtzee” Croshaw. The first one’s for Saints Row 2, which includes a great argument for why it might actually be a better game than Grand Theft Auto IV as well as a brilliant concept for a new game:

and here’s the latest review, for Dead Space, which he summarizes as “competent but bland”. Luckily, his review is anything but…

{ 0 comments }

Going Down Memory Lane with C

by Joey deVilla on September 16, 2008

July 25, 1994 issue of Time magazine
The July 25, 1994 issue of Time magazine.

The computer science student phase of my academic career (the less said about the previous phase, in which I was an electrical engineering student, the better) ran from 1991 to a successful conclusion in 1994.

If you are like me, you strongly connect memories with the music of the time; you could say that my computer science student phase ran from the time of Nirvana’s Nevermind and Soundgarden’s Badmotorfinger to Green Day’s Dookie and The Offspring’s Smash. Let’s just say that I often showed up to my classes and labs in a flannel shirt.

Album covers: Nirvana's "Nevermind" and Green Day's "Dookie"

(If that last paragraph makes you think “Whoa, that was a long time ago!”, you’ll be blown away by the fact that the initial work on C ran from the time of the Beatles’ Abbey Road to Led Zeppelin’s Houses of the Holy. A fair number of you probably weren’t even born then.)

My Student Language of Choice

I don’t know what the situation was like at other schools, but at the time, computer science students at Crazy Go Nuts University were allowed to hand in programming assignments using the following languages:

(Remember, there was no Java back then. The Green Project, from which the language/platform sprang, was still ongoing at this time, and Java was still going by its “Oak” codename.)

The general recommendation that came from most of my professors was to use Turing. They told us that it was a kinder, gentler language than Pascal and even more so than C, which they implied was designed by dyslexic aliens. When some of us suggested that it might be better to use a language that saw actual use in the real world, many of them countered with the argument that learning principles of computing was more important than learning specific languages. We might’ve responded by pointing out that one of our professors was a co-creator of Turing and probably got a vig for every Turing installation (it was a commercial language), but that might have been an academic career-limiting move.

I ignored their recommendations and went with C. In the lab, I used good ol’ cc. At home, it was Turbo C at first, and later, when I got my first Mac (a Quadra 660AV bought with money from DJing), Think C.

I never used C in my professional career. My first job out of school took me away from a world where input and output was all printf() and scanf() to interactive CD-ROMs and Macromedia Director (now Adobe Director and 7 versions later), and after that, the languages remained pretty high level: Visual Basic, Python, Java, C#, NSBasic, PHP and Ruby, with only a slight detour through through Visual C++ and C++Builder.

My C Books Back Then

Cover of "The C Programming Language"

It’s almost impossible to talk about C without mentioning “K&R”, the nickname for what is considered to be the official bible of C, The C Programming Language, which was written by Brian Kernighan and Dennis Ritchie. The latest edition of the book — the second edition — is a bit long in the tooth as it was written in 1988, but for the most part, everything in this book should still apply to the current C99 standard.

I never owned a copy of the book in my student days. I signed it out when necessary from the electrical engineering/computer science library in Walter Light Hall. I did own a copy for a brief period in 2002 when my deadbeat ex-housemate left a lot of his stuff behind, but I sold it (along with most of his stuff) in order to recoup some of the money lost from his stiffing me on rent, utilities, groceries and the largest domestic phone bill I’ve ever grappled with.

Cover of "A Book on C"

The books I had while at Crazy Go Nuts University were the second edition of A Book on C and Understanding C Pointers (a book that seems to be no longer in print). I liked A Book on C enough to pick up the fourth edition on sale a couple of years ago, and someone out there has forgotten to give me back my copy of Understanding C Pointers (you know who you are!).

Back to C

I’ve decided to get back into C for a number of reasons.

"Internet Tough Guy" Magazine

I have to admit that one of those reasons is completely irrational: it’s ego. There’s certain geek cred that comes with having at least some proficiency in C. While I had those bragging rights back in school, I can’t honestly claim them now; I haven’t even written a file whose name ends in .c in over a decade. Luckily, I had a pretty good grasp of C back in school, and the noodling I’ve been doing with good old gcc suggests that I’ve still got it, which is pretty reassuring.

iPhone, Arduino 480 and the "Mac Guy"

I’ve also been meaning to do some development with things that are programmed in C or C dialects:

  • The Arduino electronics prototyping platform has its own programming language based on C. I’ve been meaning to try out hardware hacking with the folks at the local group HacklabTO.
  • I’ve also been thinking about putting together some Mac OS X and iPhone apps, which require Objective-C.
  • I’ve even been thinking about doing some GTK noodling, which is done in good ol’ C.

Homer Simpson's brain x-ray

Finally, there’s the matter of just making myself a better programmer by working in C by refreshing my knowledge of the low-level stuff that C requires you to work with, and also the “brain stretch” that comes with working with a language and environment (what with going back to strong typing, compiling and make) that I haven’t worked in for some time.

I’ll be doing some C coding in my spare time, as well as noodling with the Arduino programming languane and Objective-C, and I’ll be posting my notes, observations and experiences here. As I’m fond of saying on this blog, watch this space!

{ 1 comment }

How Map/Reduce/Filter Can Rock Your World

by Joey deVilla on June 16, 2008

Better late than never: C# 3.0 will feature map, reduce and filter, and Dare “Carnage4Life” Obasanjo explains how to rock these features. He concludes the article with “If your programming language doesn’t support lambda functions or have map/reduce/filter functions built in, you just might be a Blub Programmer who is missing out on being more productive because your programming language doesn’t support ‘esoteric’ or ‘weird’ features,” which sounds kind of weird in an article about C#, a language that could only be Blubbier if its name were BlubLang or Blub#. I suspect I’ve woken up in some upside-down parallel universe again!

{ 0 comments }

How to Read C Declarations

by Joey deVilla on February 6, 2008

Here’s a handy guide to reading C declarations, where things can get very confusing very quickly. Quick — what’s being declared in the line “int (*(*vtable)[])();” ?

{ 3 comments }