Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: "Michael A. Labriola" <labriola@digitalprimates.net>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Subject: RE: try/catch vs in
Thread-Topic: try/catch vs in
Thread-Index: AQHPCCLcocWxLkHpPEGh6fyhPdHyIppyWxPg
Date: Fri, 3 Jan 2014 03:42:37 +0000
Message-ID: 
 <EB6F7A48D477254EAB8F675582F80CD726F5731F@DPSBS1.digitalprimates.local>
References: <B73A2BFC-4245-46DB-A951-67CD76563D91@classsoftware.com>
In-Reply-To: <B73A2BFC-4245-46DB-A951-67CD76563D91@classsoftware.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>I know "in" can be expensive but so is try catch. I've run each though sco=
ut and it looks like the in operator is orders of magnitude faster and caus=
ed no garbage collection both when the field exists and when it >doesn't. A=
nyone have any insight/something to add?


Any chance data can be null at that point? Does your code handle that well?=
 If you are good on those fronts I think it's a very positive change. I hat=
e when try/catch is used in this way.

Mike