Java开发人员可以做出的最重要的架构性决策之一就是如何使用Java异常模型。Java异常一直以来就是社群中许多争议的靶子。有人争论到，在Java语言中 的异常检查已是一场失败的试验。本文将辨析，失败的原因不在于Java异常模型，而在于Java类库的设计者未能充分了解到方法失败的两个基本原因。 本文倡导一种对异常条件本质的思考方式，并描述一些有助于设计的模式。最后，本文还将在AOP模型中，作为相互渗透的问题，来讨论异常的处理。当你能正确使用异常时，它们会有极大的好处。本文将帮助你做到这一点。 为何异常是如此重要 Java应用中的异常处理在很大程度上揭示了其所基于架构的强度。架构是在应用程序各个层次上所做出并遵循的决定。其中最重要的一个就是决定应用程序中的类，亚系统，或层之间沟通的方式。Java异常是Java方法将另类执行结果.....
高效的Java异常处理
发布： 03:52:30
您已经赞过此文了。[DESCRIPTION]
在cts测试，整包测试过程中，概率性出现如下test case fail，单包测试必现
Compatibility Test Package: .app
android.app.cts.DialogTest
testSetDismissMessage fail junit.framework.AssertionFailedError at
android.app.cts.DialogTest.testSetDismissMessage(DialogTest.:843) (代码行号是基于Android L1的版本，如下是代码片段)
下面解释发生的原因和处理办法
[SOLUTION]
从 android.app.cts.DialogTest.testSetDismissMessage代码如下：
825 public void testSetDismissMessage() throws Throwable {826
mCalledCallback =827 startDialogActivity(DialogStubActivity.
TEST_DIALOG_WITHOUT_THEME);828 final Dialog d = mActivity.getDialog();829
830 final HandlerThread ht = new HandlerThread(&DialogTest&);831 ht.start
();832833 d.setDismissMessage(new MockDismissCancelHandler(d, ht.getLooper
()).obtainMessage(DISMISS,834 new OnDismissListener() {835 public void
onDismiss(DialogInterface dialog) {836 mCalledCallback =837 }838
}));839 assertTrue(d.isShowing());840 assertFalse(mCalledCallback);841
dialogDismiss(d);842 ht.join(100);843 assertTrue(mCalledCallback);844
assertFalse(d.isShowing());845 }
dialogDismiss(d); 这行代码只是在UI thread里sendDismissMessage到
MockDismissCancelHandler这个handler，然后waitForIdleSync()，
而Dismiss Message looper是在HandlerThread里面，若HandlerThread执行得稍微慢点(或UI thread执行得够快)，Dismiss Message还未被执行，则onDismiss未被call back，mCalledCallback还是false，则test case fail
由此分析可见，这是Google设计CTS test case时，由于不同的thread执行不同步而可能会导致的问题
此类问题解决办法：
已确定为Google Issue：google在设计cts test code时有coding defect，已提交patch，且google已apply到新版本的cts code中，详细可参考如下链接：.
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：48699次
积分：1824
积分：1824
排名：千里之外
原创：136篇
转载：17篇
(57)(63)(33)(3)CTS/GTS（18）
在Compatibility Test Package:com.android.cts.jank2 这个包里面的android.cts.jank.ui.CtsDeviceJankUi--testScrolling测项，经常会遇到
junit.framework.AssertionFailedError: Too few frames received. Monitor: WindowContentFrameStatsMonitorImpl, Expected: 50, Received: xxx. at junit.framework.Assert.fail(Assert.java:50)
上面的xxx，有的时候是一个小于50的数字，有的时候是0 &
这个cts 测项的过程和目的是：
在/cts/suite/cts/deviceTests/jank2/src/android/cts/jank/ui/CtsDeviceJankUi.java中启动 com.android.cts.ui/com.android.cts.ui.ScrollingActivity这个activity，然后模拟scroll down滑动list列表，
在list列表滑动动画过程中，统计2s内更新的帧数，是否达到50帧，若未达到50帧则fail
下面介绍这个cts fail的通常原因，还有对应的debug手法
android.cts.jank.ui.CtsDeviceJankUi--testScrolling测项 fail的原因通常有如下几种原因
1.收到的frame count 小于或接近50，如46这样的数字
=&fail原因：滑动listview的时候，因为view system和listview滑动相关的参数被修改了，导致滑动的性能受到影响
=&debug手法：
1）请检查如下2支文件相比于原始版本，做了哪些改动
frameworks/base / core/java/android/view/ViewConfiguration.java 文件中，通常关注 private static final float SCROLL_FRICTION
&frameworks/base / core/java/android/widget/AbsListView.java&&&&&& 文件中，通常关注 private float mVelocityScale
除了上述列出通常关注的两个变量外，其他变量也都要关注，看做了哪些改动
2）请检查LCM 刷新率是否达标？系统performance是否受到影响而降低？=&可观察手机通常的使用场景下，UI刷新是否卡顿，若有要先解决系统performance低的问题
2.收到的frame count为0，Received: 0
=&fail原因：cts 模拟scroll down后，由于客户客制化原因，使得画面更新的区域并不在listview的区域内，导致并未收到listview更新的任何帧，故fail
=&debug手法：
&&& 1）请确认手机是否有硬体按键？检查是否有对Navigationbar的显示做过客制化？若有，请恢复成原始设计
&&& 2）若对第1）条未做改动，那么需要在eng或userdebug版本上，adb命令打开debug开关，查看为何没有更新listview所在区域？
需要打开的debug开关如下：
adb shell setprop debug.viewroot.enable e0002
&adb shell setprop debug.listview.dumpinfo 1111111
&adb shell &start&
然后抓取cts test fail的完整mtklog来分析
分析的时候，主要在com.android.cts.ui.ScrollingActivit的进程中search 如下这样的关键log：
01-01 05:29:46.945
V ViewRootImpl: Invalidate child: Rect(0, 1140 - 720, 1184),this = ViewRoot{e5c0e9b com.android.cts.ui/com.android.cts.ui.ScrollingActivity,ident = 0}
然后观察下面画面刷新的callstack是由谁触发的
01-01 05:29:46.945
V ViewRootImpl: java.lang.Throwable: invalidateChildInParent
01-01 05:29:46.945
V ViewRootImpl: at android.view.ViewRootImpl.invalidateChildInParent(ViewRootImpl.java:1109)
cts 所跑的时间段可以通过如下log来确认：
TestRunner: started: testScrolling(android.cts.jank.ui.CtsDeviceJankUi)
TestRunner: finished: testScrolling(android.cts.jank.ui.CtsDeviceJankUi)
3.cts fail的log与frame count无关
例如下面的fail log：
&& &FailedScene message=&java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Native Method)
&&
&&StackTrace&java.lang.reflect.InvocationTargetException
&at java.lang.reflect.Method.invoke(Native Method)
&at android.support.test.jank.JankTestBase.runTest(JankTestBase.java:116)
&at junit.framework.TestCase.runBare(TestCase.java:134)
&at junit.framework.TestResult$1.protect(TestResult.java:115)
&at android.support.test.internal.runner.junit3.AndroidTestResult.runProtected(AndroidTestResult.java:77)
&at junit.framework.TestResult.run(TestResult.java:118)
&at android.support.test.internal.runner.junit3.AndroidTestResult.run(AndroidTestResult.java:55)
&at junit.framework.TestCase.run(TestCase.java:124)
&at android.support.test.internal.runner.junit3.NonLeakyTestSuite$NonLeakyTest.run(NonLeakyTestSuite.java:63)
&at android.support.test.internal.runner.junit3.AndroidTestSuite$1.run(AndroidTestSuite.java:98)
&at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
&at java.util.concurrent.FutureTask.run(FutureTask.java:237)
&at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
&at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
&at java.lang.Thread.run(Thread.java:818)
&Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.support.test.uiautomator.UiObject2.fling(android.support.test.uiautomator.Direction)' on a null object reference
&at android.cts.jank.ui.CtsDeviceJankUi.testScrolling(CtsDeviceJankUi.java:58)
&... 15 more
&&/StackTrace&
=&fail原因：不明原因的客制化引起cts的测试过程出错，还未跑入该项具体的cts test 流程
=&debug手法：
1）先check view system的几支主要文件是否做过改，然后再请cts framework的人做进一步做分析，因为该结果显示TestRunner都没跑起来
/frameworks/base/core/java/android/view/View.java
&/frameworks/base/core/java/android/view/ViewGroup.java
&/frameworks/base/core/java/android/view/ViewRootImpl.java
2）再检查是否只有这一项cts test fail？根据这种fail log，应该是有非常多的test都会fail，需要从cts test的测试注意事项和流程方面入手分析
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：22112次
排名：千里之外
原创：26篇
转载：11篇
评论：46条
(1)(3)(17)(7)(5)(1)(3)Java开发人员可以做出的最重要的架构性决策之一就是如何使用Java异常模型。Java异常一直以来就是社群中许多争议的靶子。有人争论到，在Java语言中 的异常检查已是一场失败的试验。本文将辨析，失败的原因不在于Java异常模型，而在于Java类库的设计者未能充分了解到方法失败的两个基本原因。 本文倡导一种对异常条件本质的思考方式，并描述一些有助于设计的模式。最后，本文还将在AOP模型中，作为相互渗透的问题，来讨论异常的处理。当你能正确使用异常时，它们会有极大的好处。本文将帮助你做到这一点。 为何异常是如此重要 Java应用中的异常处理在很大程度上揭示了其所基于架构的强度。架构是在应用程序各个层次上所做出并遵循的决定。其中最重要的一个就是决定应用程序中的类，亚系统，或层之间沟通的方式。Java异常是Java方法将另类执行结果.....
高效的Java异常处理
发布： 03:52:30
您已经赞过此文了。