Comments for Papirfly Blog

Comment on Do they test at all? by Torbjørn

Torbjørn — Mon, 12 Oct 2009 05:47:07 +0000

Look like Adobe thinks the same as us – Flashplayer 10.1 allows for a global error event listener that handles any ErrorEvents not handled explicitly. Yay!

Comment on ErrorEvent – equivalent to throw new Error? by Derf

Derf — Thu, 01 Oct 2009 01:27:12 +0000

In as3 we don’t have access to EventManager (or whatever its name is), but its has more or less a structure like [eventType][dispatchers][listeners], so when an event is dispatched, this manager can test is the event is an ErrorEvent.
And if there’s no listener registered to this dispatcher/eventType pair, an uncatchable error is thrown.

Comment on Do they test at all? by Torbjørn

Torbjørn — Fri, 25 Sep 2009 07:10:33 +0000

The problem is that you can’t try … catch errors that are the result of an asynchronous operation like eg. load(url) – and external communication is an operation that certainly can fail.

I try to avoid try … catch – in most cases a if statement does the job, which gives me more readable code as the possible causes of errors are explicitly tested for instead of just generically caught. Another reason to be careful with try … catch is that throwing errors is time consuming. If you rely on it as code logic, things run a lot slower than necessary

Comment on Do they test at all? by Riccardo Bartoli

Riccardo Bartoli — Thu, 24 Sep 2009 14:49:52 +0000

Yes it’s a nightmare, but I prefer to catch my errors instead of adding listeners for them (unless needed).

People must learn that everything that can possibly throw an error must be enclosed in this block of code:

try
{
// your code here
}
catch(e:error)
{
// catch you error here
}

Comment on Do they test at all? by Torbjørn

Torbjørn — Thu, 24 Sep 2009 11:39:39 +0000

You’re right – a way of listening for error event globally would be great. But still – handling errors on loaders is a no-brainer.

Comment on Do they test at all? by expertbuddy

expertbuddy — Thu, 24 Sep 2009 11:29:29 +0000

It keeps remaining that there needs to be a global event handling mechanism which is missing in Adobe Flash player rather than controlling the individual errors.

Comment on Flex API bug by Torbjørn

Torbjørn — Wed, 29 Jul 2009 05:45:16 +0000

After posting, I found a situation where this really messes things up. If you compile an Air app, the NativeDragManager will handle all drags. It transfers the dragSource data into a Clipboard instance. Seems reasonable? But Clipboards setData method doesn’t allow parameters to be null at all. So if a value in dragSource was numeric zero, it will be ‘translated’ into null which causes an Error from Clipboard. To be fair – the documentation of Clipboard states that if you use a custom format string (which we are now), the values should be an object reference or clone. But dragSource does not say anything about that.

Comment on Flex API bug by Torbjørn

Torbjørn — Wed, 29 Jul 2009 05:33:00 +0000

I like your solution better – nice. Haven’t used hasOwnProperty() much.

Comment on Flex API bug by Torbjørn

Torbjørn — Wed, 29 Jul 2009 05:28:27 +0000

Value objects are good in some cases, but it seems unnecessary to create an object to store a single value.
Yes – casting into int would be a good workaround, as long as it’s int. In this case the number could have decimals. The point is not so much how to work around it, but whether Adobes implementation needs to behave like this or whether it’s a bug.

Comment on Flex API bug by Josh Tynjala

Josh Tynjala — Tue, 28 Jul 2009 21:01:45 +0000

I’d call it a bug. I think they should simply check to see if the format exists:

if( dataHolder.hasOwnProperty( format ) )
{
return dataHolder[ format ];
}

This should allow null values too, I think, but not undefined. Like with zero, I could see some potential use-cases for null, though not as common.