[
https://issues.apache.org/jira/browse/FLEX-17210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14558404#comment-14558404
]
Chris Martin commented on FLEX-17210:
-------------------------------------
This is why I wanted to reach out to you. Right now we are thinking to not
throw the exception. Maybe log a warning trace line. And then take a look at
the mustella tests to see if we can get this exception to be handled correctly
so we can get all tests to complete. When we reviewed this ticket, it seems
the "Issue here is locale doesn't exist or was not compiled into application".
Which is a user error in making sure the right assets have been loaded before
attempting to reference them.
Yep, we know what the issue is with having the exception present. I explained
it in detail in the above referenced email in the archive. The exception
ultimately causes us to not run the full 418 mustella tests for
ResourceManager. Depending on system you can get up to 14 and at time 8 to pass
before the test times out. Only one test gets logged as a failure to due to a
timeout, so the subsequent with -failures only re-tests the one test that timed
out, and not the remaining ones.
Do you know of a way to trap this exception that we added as the new expected
result for that mustella test,
ResourceManager_Methods_findResourceBundleWithResource
RTL_ResourceManager_Method_findResourceBundleWithResource_1LocaleChainItem_InvalidLocale.
The test specifically is dealing with referencing a resource bundle which is
invalid. I'd naturally think that we wrap whatever is making the call with a
try catch and then in the catch identify that we are expecting to be there to
pass the test, and if we don't have the exception then the test now fails.
I'm not too familiar with how mustella tests are built up.
> mx:NumberFormatter failed when use localeChain
> ----------------------------------------------
>
> Key: FLEX-17210
> URL: https://issues.apache.org/jira/browse/FLEX-17210
> Project: Apache Flex
> Issue Type: Bug
> Components: Formatters
> Affects Versions: Adobe Flex SDK Previous
> Environment: Affected OS(s): Windows
> Affected OS(s):
> Language Found: English
> Reporter: Adobe JIRA
> Assignee: Justin Mclean
> Labels: easytest
>
> Steps to reproduce:
> <?xml version="1.0" encoding="utf-8"?>
> <mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml";
> layout="absolute" creationComplete="onCC();">
> <mx:Script>
> <![CDATA[
> import mx.formatters.NumberFormatter;
>
> private function onCC():void
> {
> var nf:NumberFormatter = new NumberFormatter();
> nf.precision = 2;
> resourceManager.localeChain = ['zh-Hans'];
>
> trace("number:"+nf.format(1/3));
> resourceManager.localeChain = ['en_US'];
> trace("number:"+nf.format(1/3));
> }
> ]]
> >
> </mx:Script>
> </mx:WindowedApplication>
>
> Actual Results:
>
> number:
> number:0.33
>
> Expected Results:
>
> number:0.33
> number:0.33
>
> Workaround (if any):
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
