关于代码健壮性

今天有许多客户反映我们的APP的一打开就崩溃,因为是首页的是我做的,我马上打开APP看看,果然如此。我的同事debug了代码,原来的首页的banner图片返回是NULL,这是服务端那边返回的,我们无法控制的。但是我们客户端就没有责任吗?我们做客户端不能保证服务端一定有给我们返回数据,有些情况下可能为NULL。今天就正好就发生了这种情况。看了下我的代码,我的就加了一层判断首页返回的model类的对象不为空,但是没有判断banner的图片信息返回是否为空。如果为空,我也赋值给了viewpager,肯定为crash的。后来我加了一层判断是否为空。即使没有图片返回,应用也不会崩溃了。用到哪个信息,就要判断是否为空。服务端返回的数据返回可以为空,但是我们不能因此就让应用crash,信息不显示没有关系,但是尽量不能让应用有crash的现象,这不仅用户体验差,而且还显示程序员的代码不够健壮。以后我要尽量写出健壮的代码,这个习惯对一个程序员非常重要。

时间: 2024-10-18 02:05:09

关于代码健壮性的相关文章

代码健壮性是真的好吗?

我在看一个视频,这个视频里写的代码有这个特点,那就是它把代码写的一个方法可以多次被调用或者说叫利用也可以;同时视频也在一致强调这一点;那我就疑惑了,代码健壮性就那么好吗? 首先,你要写的一个方法能实现不同的功能,在开始设计它的时候就要考虑到各个问题的方方面面,这个对精力应该也是一个很大的消耗吧:这些代码也许写的人能轻松的能读懂,但是如果是别人来读的话,那耗费的时间和精力应该是更大的:如果是更大型的软件,恐怕程序员都要白头了吧:这难道是炫耀技术吗?这个代价也太大了! 其次,现在电脑运算速度是很快的

关于提高代码质量的思考之提高代码健壮性

接着上期的拓展性之后,今天谈谈代码的健壮性.代码的健壮性又称鲁棒性,是高质量代码的一个重要指标. 有人分析了印度软件行业比中国好的一个原因:印度的一个老程序员,月代码量在一千行左右,这一千行代码,算法平实,但都是经过仔细推敲,实战检验的代码,不会轻易崩溃的代码.我们的程序员,一天就可以写出一千行代码,写的代码简短精干,算法非常有技巧性,但往往是不安全的,不完善的.印度人的程序被称作:傻壮.但程序就得这样! 那么如何写出一个代码简短精干,算法非常有技巧性,而又非常安全的代码呢?我逛了很多论坛,发现

linux下,简单一行代码提高脚本的健壮性

前言 新来的美女同事,拿她写的脚本向我请教时,我证实了程序猿经常说的一句话:OMG,这么狗屎的代码居然是我写的!!! 问题描述: 在linux/unix写脚本时,我大多习惯在第一行加上(或许还有一大班跟我一样习惯的人): #!/usr/bin/bash 或者 #!/usr/bin/perl 或者 #!/usr/bin/python…………………… 用于操作系统执行这个脚本的时候,调用/usr/bin下的bash/perl/python解释器. 但是,这时存在两个小小问题: 1.本机的bash/p

采用[ICONIX] 方法实践分析和设计之四 [健壮性分析]

在前三章中通过(问题域)建模和用例分析之后,在许多的UML书中可能接下来就要进行时序图和协同图的绘制了.但是问题好像还没那么简单,因为这里有一条鸿沟还没有跨过去,正如下图所示:                    在我刚学开始学习 UML时,在拿到用例文本时要去画时序图总感觉有些别扭,不知如何才能将文本中的意思完全用图的形式表达出来,总是感觉分析出来的文本中缺了一些很重要的东西, 而这些被丢掉的对象最终可能会导致无法绘制时序图,但又找不出用例文本中到底还有什么东西被遗漏,最终导致设计瘫痪.后来

性能测试 - 响应 vs 延迟 vs 吞吐量 vs 负载 vs 扩展性 vs 压力 vs 健壮性

本文译自Niraj Bhatt 所著 Performance Testing - Response vs. Latency vs. Throughput vs. Load vs. Scalability vs. Stress vs. Stress vs. Robustness. 原文地址:https://nirajrules.wordpress.com/2009/09/17/measuring-performance-response-vs-latency-vs-throughput-vs-lo

python Selenium2Library element操作的健壮性封装、普通操作不受影响

"""     对Selenium2Library element操作的健壮性封装.普通操作不受影响.     每个element操作方法生成一个操作对象    ''' 2类对象:         father类型: fatherName=None eleMethodName=webObj.browserName,            一般在webObj创建时配套创建, _eleMethod_objDc中记录,形如{fatherName:{}}        非father

【软件构造】第七章第一节 健壮性和正确性的区别

第七章第一节  健壮性和正确性的区别 第七章:进入软件构造最关键的质量特性 --健壮性和正确性. 本节在1-2节的基础上,重申了Robustness and Correctness的重要性,澄清了二者之 间的差异,并指明了在软件构造中处理二 者的典型技术(防御式编程.异常处理. 测试.调试等) Outline 健壮性(Robustness)和正确性(correctness) 如何测量健壮性和正确性 Notes ## 健壮性(Robustness)和正确性(correctness) [健壮性] 定

软件构造复习——7.1健壮性与正确性

一.健壮性和正确性的简单介绍 1.1Robustness  健壮性 1.1.1 定义:健壮性又称鲁棒性,是指软件对于规范要求以外的输入情况的处理能力.所谓健壮的系统是指对于规范要求以外的输入能够判断出这个输入不符合规范要求,并能有合理的处理方式. 简单来说就是系统在正常输入或不正常外部环境下仍能够表现正常的程度. 1.1.2面向健壮性编程的做法 处理未期望的行为和错误终止 即使终止执行,也要准确/无歧义的向用户展示全面的错误信息 错误信息有助于进行debug 1.1.3面向健壮性编程的原则 总是

程序try-catch的绝对健壮性之嵌套

写程序的过程中,我们对try-catch在熟悉不过了,捕获异常进行处理,以保证程序的健壮性. 今日突发一想,如果我们catch中的代码异常了怎么办?我们做以下一种假设 static void Main(string[] args) { try{ //Code A } catch{ //Code B } finally{ //Code C } } 按照我们平时经常用的,我们在Code A的位置执行出错之后,我们最后可能在Code B进行错误处理,然后可能在Code C处写错误日志. 那么问题来了,