Comments on: Error Handling in ActionScript 3: Don’t Make Grenades (or how to not crash Safari)

By: Flex and Flash Developer – Jesse Warden dot Kizz-ohm » Blog Archive » Consulting Chronicles #2: Fixing a Pile of Rubbish – Part 1

Mon, 28 Dec 2009 14:41:20 +0000

[…] goes in line with my don’t create grenades theory of ActionScript, but taken a step farther. Â It’s one thing to wrap URLLoader’s […]

By: Tim Oxley

Tim Oxley — Mon, 02 Nov 2009 06:56:48 +0000

A suggestion while developing may be to use ErrorEvent as your primary Event, but use conditional compilation to swap this out for the Event class when releasing the production version.

By: Error Handling in ActionScript 3: Donâ€™t Make Grenades (or how to not crash Safari) « rabbitpot

Fri, 19 Jun 2009 10:06:12 +0000

[…] on Error handling in AS3, and specifically the increasing issue in Safari Browers, so definitely check it out, well worth the long read. « Solution #6: Error creating […]

By: Flash Gordon

Flash Gordon — Sat, 13 Jun 2009 09:02:10 +0000

Thanks for a great article Jesse. I have been dabbling in ActionScript for a couple of years now and I will freely admit that handling errors did not enter my coding practice at all. This was in part due to me just learning the nuts and bolts first but mainly because I didn’t think I would ever have to handle errors anyway since my coding was just for fun. Just recently though I have begun writing code for real-life situations and suddenly the need for error handling has jumped out and bit me hard an my ass! The shame and embarrassment of it when you demo an app and Flash Player immediately spits out an error dialogue! Anyway my point is that you writing this article has come at the exact time I was looking into the whole error handling thing. Much more understandable than the official documentation for me.

Thanks man!

By: Arthur Debert

Arthur Debert — Fri, 12 Jun 2009 21:26:05 +0000

Hi Jesse.

An excellent write up. This is definitely one area that has received little love from the actionscript community.

Some “error” conditions are expected, such as not finding a value on a list or in a hash. In those cases a return code that signals that error is appropriate.

But somethings are unpredictable, since they depend on other systems (http requests, writing to disk). Basically any IO is outside of your control. For those cases an exception makes sense, it’s not something that you control (you could’ve anticipated it, though).

It’s also a pity that the native api / event is so awkward, no way to catch all and other oddities. We’d be much better off if all loading operations would dispatch a general error containing more details to be inspected latter on, for example.

As a sidenote, the netstream.close was the only case where the native api would throw an exception in AS2, as far as I can remember.

Cheers