编程匠艺笔记.docx
《编程匠艺笔记.docx》由会员分享，可在线阅读，更多相关《编程匠艺笔记.docx（80页珍藏版）》请在冰点文库上搜索。
编程匠艺笔记
第一章善于防守
使程序正确和使程序能用的区别：
1.编写在大多数情况下都能用的代码是很容易的，它对常规的输入集会产生常规的输出集；2.正确的代码绝对不会崩溃，对于所有的输入集，它的输出都将是正确的；3.并非所有正确的代码都是优秀的代码，因为有些正确的代码的逻辑可能很难理解，难以维护。
在编写代码的时候，你会很容易产生很多设想，例如程序应该如何运行、如何调用、如何输入等。
我们经常有以下3种常见的设想：
1.这个函数“绝对不会”被那样调用，传递给我的参数总是有效的；2.这段代码肯定会“一直”正常运行，它绝对不会产生错误；3.如果我把这个变量标记为“仅限内部使用”，就没有人尝试访问这个变量。
不要做任何设想，没有记录下来的设想会不断的制造缺陷，特别是随着代码的增长。
凡是可能出错的事，准会出错。
防御性编程是一种细致、拘谨的编程方法。
为了开发可靠的软件，我们要设计系统的每个组件，以使其尽可能的“保护”自己，我们通过明确的在代码中对设想进行检查，击碎了未记录下来的设想。
这是一种努力，防止我们的代码被以一种错误的方式调用。
防御性编程不是检查错误，不是测试，也不是调试。
对于防御性编程的反对观点：
1.降低了代码开发的效率；2.混淆了代码的职责，代码在执行必要的业务逻辑外，也要对各种设想进行判断。
对于防御性编程的支持观点：
1.节省大量的调试时间；2.编写可以正确运行、只是速度有些慢的代码，要好于编写那些大多数时间都正常运行、但是有时会崩溃的代码；3.我们这里所考虑的大部分防御性措施，并不具有任何明显的性能开销；4.防御性编程避免了大量的安全问题。
我们可以使用一些编程技巧来进行防御性编程
使用好的编码风格和合理的设计。
这样可以防范大多数的编码错误。
最好地计算机程序的文本是结构清晰的。
不要仓促的编写代码。
要三思而后行，一方面，要对将要写的代码出现的各种可能情况进行分析；另一方面，一定要在完成与一个代码段相关的所有任务后，再进入下一个环节。
不要相信任何人。
不要设想所有的一切都运行良好，或者所有的代码都能正确的运行，用怀疑的眼光审视所有的输入和输出，知道你能证明它们是正确的。
编码的目标是清晰，而不是简洁。
请保持代码简单。
不能维护或者难以维护的代码是不安全的。
不要让任何人做他们不应该做的修补工作。
内部的事情就应该留在内部。
在开始编码时就应用防御性策略，要比改进代码时才使用容易的多。
编译时打开所有警告开关。
编译器的警告可以捕捉到很多愚蠢的编码错误。
在任何情况下都应该打开你的编辑器的警告功能，警告的出现总是有原因的。
使用静态分析工具。
使用安全的数据结构。
检查所有的返回值。
不要让错误悄无声息的侵入你的程序；忍受错误会导致不可预知的行为。
不论何时，都要在适当的级别上捕获和处理相应的一场。
审慎的处理内存和其他宝贵的资源。
对于在执行期间获取的任何资源，必须彻底释放。
不要因为觉得操作系统会在你的程序退出时清除程序，就不注意关闭文件或者释放内存。
在声明位置初始化所有变量。
即应该将变量的声明和初始化放在一起，这样可以放置对未初始化的变量进行操作。
尽可能推迟一些声明变量。
可以使变量的声明位置和使用它的位置尽量接近，从而防止它干扰代码的其他部分。
不要在多个地方重用一个临时变量，变量重用会使以后对代码重新完善的工作变得一场复杂。
使用标准语言工具。
使用好的诊断信息日志工具。
审慎的进行强制转换。
强制转换不仅可能会造成转换一场，还可能造成变量的精度发生变化。
我们可以使用约束来对我们的设想进行验证。
约束分为：
1.前置条件；2.后置条件；3.不变条件；4.断言。
优秀的程序员：
1.关心他们的代码是否健壮；2.确保每个设想都显式的体现了防御性代码中；3.希望代码对无用信息的输入有正确的行为；4.在编程的时候认真思考他们所编写的代码；5.编写可以保护自己不受其他人的愚蠢伤害的代码。
糟糕的程序员：
1.不愿意去考虑他们的代码出错的情况；2。
为集成才发布可能出错的代码，并希望别人会找到错误；3.将关于如何使用他们代码的信息仅仅攥在手里，并随时都可能将其丢弃；4.很少思考他们正在编写的代码，从而产色很难干不可预知和不可靠的代码。
第二章精心布局
编码的风格曾经是、现在是、将来也将继续是程序员之间信仰之争的主题之一。
编程样式极大的影响了代码的可读性，没有人愿意使用读不懂的代码。
我们的代码一般有3类读者：
1.我们自己，我们不仅需要能够读懂刚刚写下的代码，也需要在多年之后仍然能够明白它的意思；2.编译器，关注语法，不关注样式；3.其他人，这类人最重要，也最容易被忽视。
什么是好的样式？
1.一致；2.传统，采取一种业内流行的样式；3.简洁。
括号的样式风格：
1.K&R风格；2.悬挂式风格；3.缩进式风格；4.其他风格。
好的样式风格不止一种，各种风格的品质和适用性取决于使用的环境和文化背景。
选择一种好的编码风格，并坚持使用它。
多种风格有助于我们写出更好的代码。
对于一个组织来讲，是需要一种内部的编码风格的。
这样可以提高代码的质量，并使软件开发更加安全。
所有人共同分享同一种风格所带来的好处，远远超出了为了同意而付出的代价，即使不赞同这个标准，你也应该遵守它。
当一个组织内么有一个明确的编码风格时，我们需要制定一份。
这是一项需要谨慎考虑的任务。
应该恰当而坚决的开展。
一个良好的个人风格对于整个团队的程序员不一定是最好的。
你要创建的标准不应当只适合你自己的审美习惯，它应该使团队的代码合为一体，并避免常见的问题。
创建编码风格时可以采取的策略：
标准为谁而立？
圈定使用范围。
赢得广泛参与。
有参与才会更乐意遵守。
做出成果。
最终应该有一份可以理解的文档。
使最佳做法标准化。
突出重点。
避免热点。
把罕见且麻烦的情况留给个人决定，前提是不会造成太大的分歧。
逐步完善。
为推广做计划。
创建编码风格时，需要注意掌握分寸，不是规定的越细越好。
我们有理由认为：
版面漂亮的代码是经过精心设计的代码，格式混乱的代码一定没有好好下功夫。
优秀的程序员：
1.避免无意义的争论，对别人的意见非常敏感；2.谦虚克己，不认为自己永远是对的；3.懂得版面是如何影响可读性的，并努力写出可能清晰的代码；4.采用内部样式，即使内部样式与他们的个人偏好相矛盾。
糟糕的程序员：
1.闭目塞听，固执己见，认为”我的观点才是正确的“；2.和每个人争论最琐屑的小事，把这些当成成证明自己优势的机会；3.没有始终如一的个人编码风格；4.对别人代码的风格指手画脚。
第三章名正言顺
远古的人认为命名某个事物就是对其拥有权利。
这不仅仅是简单的宣称所有权。
一些人对名字的力量坚信不疑，以至于他们从不将自己的名字告诉陌生人，因为他们害怕陌生人会使用名字来伤害他。
名字所描述的内容包括：
1.身份；2.行为；3.识别，名字将一个事物标明为一个性质独特的实体。
我们为什么应当恰当的命名呢？
因为编写源代码就是关于如何进行清晰的交流，恰当的命名意味着“了解名称就可以了解对象”。
清晰的命名是优秀代码的特点之一，一个对象的名称应该清晰的描述了这个对象。
在编码时，需要进行命名的内容包括：
1.变量；2.函数；3.类型；4.命名空间或者包的名字；5.宏；6.源文件名称。
为了恰当的命名，在为一个对象想出名称以前，必须准确的了解这个对象是什么，如果你不知道你所命名的对象是什么，它的用途和它存在的理由，你怎么能够赋予它一个有意义的名字呢？
所以说糟糕的名称通常表明你对需要命名的对象缺乏理解。
一个好的名称具有以下特点：
技术上正确。
符合所使用的语言在命名上的限制。
符合语言习惯。
要了解你的语言的命名规则，更重要的是，了解这种语言的习惯用法，公共命名约定是什么？
应用这些语言习惯和约定。
恰当。
包括以下几点：
1.长度，在进行命名是，将重点放在清晰而非简洁上，慎用各种奇怪的所写；2.格调，一般在命名时不要使用语气助词。
理解在较短的名称和较长的名称之间进行权衡的考虑因素，即它们是如何依赖于变量的作用范围的，对于循环计数器这种变量，就可以简单的以i来命名，但是要注意在多重循环时，最好起一个易理解的名字。
如何命名一个变量：
一般情况，变量用一个名词来表示。
如何不是名词，通常会是一个名词化的动词。
有很多用于修饰成员变量的面向对象的语言约定，以说明它们是成员，而不是局部变量或者全局变量。
一种常见的命名习惯是使用首字母缩略词作为简洁和“有意义”的名称，例如：
我们可以这样声明一个变量：
SomeTypeWithMeaningfulNamingstwmn（10）;
一般情况下，将类姓名和变量名区分开，类姓名通常都有一个大写的首字母，而变量名则具有小写的首字母，例如：
我们可以这样声明一个变量：
Windowwindow;
如何命名函数：
如果变量像一件可以握在手里的东西，那么函数就是你拿这件东西所做的事，它的名字在逻辑上更应该是一个动词。
有意义的函数名字应该避免使用be、do和perform等词语。
我们应该隐藏函数内部的具体实现过程，始终从使用者的角度来为函数命名。
但是当在为请求信息的简单查询函数进行命名的时候，可以不必遵守。
当你编写一个函数时，应该使这个函数很好的文档化，其名称应该仍然是关于函数用途的一个清晰的描述，这是函数契约的一部分。
如何命名类型：
对类的命名没有太多严格的直觉推理法，因为不同的类有不同的用途。
在名称中避免使用多余的词，尤其实在类型名中避免使用以下这些词语：
class、data、object和type。
要确保你描述的数据的类不是一个真正的对象。
糟糕的类名会使程序员们感到困惑，较好的命名能为代码的逻辑提供清晰的思路。
如何命名名字空间：
选择描述其内容的关系的词语。
不要选择重复暗示命名对象是一个集合的名称，例如：
controls_group就不是一个好的名称。
如何命名宏：
名字全部使用大写字母。
不要为其他任何对象使用这种全部大写的名称。
如何命名文件：
注意大小写，一些文件系统不区分大小写。
确保同一目录中的文件名不仅仅只是大小写不同。
尽量保证你创建的文件都具有不同的名称，即使这些文件都分布在不同的目录中。
一个好的名字，具有以下特点：
保持前后一致，命名一致不仅限于创建名称时的大小写和格式化，一个名称将确立一个隐喻，在这个程序中，这写隐喻应该保持一致。
利用代码的内容，我们要充分利用上下文，写出简洁的、描述性的以及没有多余信息的名称。
使用对你有利的名字。
一个好的名字，不应该具有的特点：
含义模糊。
啰嗦。
不准确或使人误解。
有歧义或者含糊不清。
太做作。
优秀的程序员：
1.意识到名字的重要性并尊重它们；2.为他们创建的所有对象都考虑如何进行命名，并且选择恰当的名称；3.使许多考虑因素保持平衡，包括名字的长度、清晰度、上下文等；4.从整体的视角来命名，因此他们的名称在一个项目中都保持一致。
糟糕的程序员：
1.不关心他们的代码是否清晰；2.很快的编写代码而很少进行思考；3.忽视语言的自然习惯；4.命名时前后不一致；5.不从整体的角度进行思考，不考虑他们的代码怎样和整体相结合。
在许多不同的上下文中，重复使用同一个局部变量名是完全可以接受的。
不要用局部变量名隐藏全局变量名，这样容易造成混淆。
优秀的编码高手会把良好的命名当做一种习惯，而且不需要编码规范来“约束”。
第四章不言自明
创建优秀的代码以为着创建良好文档化了的代码。
编写代码是一件艰苦的工作，将代码文档化更是艰苦异常。
就像代码一样，文档必须接受版本控制，你必须要确保你阅读的文档的版本和你正在处理的代码的版本保持一致。
唯一能够完整并正确的描述代码的文档就是代码本身。
这并不自然而然的以为着代码本身就是最佳的描述，但是在通常的情况下，这是你能够获得的唯一文档。
编程语言是我们交流的媒介，清晰地交流至关重要。
清晰的代码会活的较高的质量，因为你犯错误的可能性降低了，而且这样的代码维护的成本也比较低。
自文档化的代码有很高的可读性。
如何编写自文档化的代码：
使用好的样式编写简单的代码。
1.让“正常”的流程明显的贯穿你的代码，错误的情况不应该扰乱程序的正常执行流程；2.避免过多的使用嵌套语句；3.要谨慎的优化代码，如果一定要优化，那么要清晰的注册这段代码发生了哪些变化。
选择有意义的名字。
好的名字也许是我们避免多余注释的最好办法。
分解为原子函数。
1.一个函数，一种操作；2.减少任何出人意料的副作用；3.保持简短，短小的函数易于理解。
选择描述性的类型。
命名常量。
避免在程序中进行“硬编码”，避免使用神奇数字。
强调重要的代码。
1.在类中按一定顺序进行声明；2.尽可能隐藏所有不重要的信息；3.不要隐藏重要的代码；4.限制嵌套的条件语句的数量。
要确保所有重要的代码非常突出，并且易于阅读，将任何目标读者不关心的内容都隐藏起来。
分组相关信息。
提供文件头。
在文件的顶部放置一个注释块，以描述文件的内容以及该文件所属的项目。
恰当的处理错误。
在最恰当的上下文中处理错误，不要返回无意义的错误。
编写有意义的注释。
清晰的代码应该包含“适量”的注释（“适量”：
只有在你无法以任何其他方式来提高代码清晰度的情况下，再添加注释）。
实现自文档化的方法：
文学性编程。
你不是在编写程序，你是在编写文档。
源代码就是文档。
高质量的文档永远都取决于编写策划那个徐的程序员。
文学性编程实际上是带有设计的传统代码与实现规范这两者的结合。
文档化工具。
例如JavaDoc和NDoc。
写作的技巧就是创建一个上下文环境，别人在其中思考。
优秀的程序员：
1.努力编写清晰、自文档化的代码；2.尽量编写所需的最小量的文档；3.考虑哪些需要维护其代码的程序远门的需求。
糟糕的程序员：
1.对于他们所编写的难以理解的代码非常骄傲；2.尽力避免编写各种文档；3.不关心更新文档的问题；4.认为：
如果我写起来很困难，那么别人理解起来也会很困难。
如何将相关代码进行分组，一般有以下几种方法：
1.名称前缀或后缀；2.文件系统中的位置；3.将相关内容放置到一个类中或者结构中。
如果有良好的代码文档，那么一个新手就应该很清楚代码中的某个部分有什么作用。
编码规范或者编码风格虽然有一定作用，但是没有什么可以取代精明、合理的编程。
愚蠢的程序员即使遵守最严格的标准，也仍然会写出很差的代码。
第五章随篇注释
注释非常像意见，你可以随心所欲的做注释，但这仅仅是因为做注释并不意味着这些注释就是正确的。
注释可以将优秀的代码和糟糕的代码区分开，将粗糙复杂艰涩难懂的逻辑与清晰友好的算法区分开。
但是我们不需要过分夸大注释的作用，如果你已经编写出真正优秀的代码，那么注释就像蛋糕上的糖衣。
好的注释是避免让人望而生畏代码的一种策略，注释本身并不能够让糟糕的代码变得好一些。
什么是代码注释？
从语法的角度来看，注释就是编译器将忽略不计的原代码块；从语义的角度来看，注释是昏暗肮脏的小路和明亮通畅的大道之间的区别，你可以使用它来强调某个特殊的问题领域，或哟工作头文件的记录媒介。
注释的目标读者是人，而不是计算机，如果我们想要提高注释的质量，就必须了解并满足人们在阅读代码时所真正需要的。
代码注释不是你应该放在代码中的唯一文档。
注释不是规范，不是设计文档，也不是API参考。
注释是一种总是会物理的附在代码上的宝贵的文档形式，是一种内部的文档化机制。
注释的形式各种各样，从根本上说，编写注释是一个主观的问题。
学会只编写够用的注释，过犹不及，我们要重视质量，而不是数量。
阅读你的注释的人也会阅读你的代码，因此尽可能在代码本身中进行文档化，而不要编写大量的注释。
要将你的代码语句看做是第一级的注释，并让代码自文档化。
编的好的代码实际上并不需要注释，因为每行代码都可以自我解释。
我们应该把时间花在编写不需要大量注释支持的代码上。
注释中应该有哪些东西：
解释为什么，而不是怎么样。
你应该改为几种描述为什么有些东西要这样写，或者下一个语句块最终要起到什么作用。
当我们维护一段代码时，解释这段代码为什么存在的理由很少发生变化，但是这段代码的实现其目的的方法却很容易发生变化。
不要描述代码。
无价值的描述性注释有时很明显，没有必要用英语费力的重复叙述代码，除非你要文档化一个相当复杂的没有注释就无法理解的算法。
不要取代代码。
当你发现自己在编写密密麻麻的注释来解释你的代码时，赶快停下来，想一想是不是有一个更大的问题需要解决。
确保注释有用。
好的注释犹如好的代码；它有如下特点：
1.记录意想不到的内容；2.讲真话；3.有价值；4.清晰明了；3.容易理解。
避免分心。
注释的作用是说明周围的代码，因此我们必须避免所有干扰这个作用的因素。
注释应当只是增加价值。
需要避免以下形式的注释：
1.过去的事情；2.你不想要的代码，不要把需要剔除的代码包含在注释中；3.ASCII技术；4.代码块的结尾，应该与开头一起先是在同一页中，而且代码的版面应该是块的开头和结尾都一目了然。
不要文档化差劲的代码——重写这些代码。
良好的注释应该有些原则是可以参考的，如下：
一致性。
所有的注释都应该清晰明了，前后一致。
为你的注释选择一种特定的布局方式，并且始终坚持使用这种方式。
清晰的块注释。
要充分考虑到你的注释可能会被看到的环境，不要太沉迷于具有高亮显示的编辑器中。
清晰的注释应该让文字上下对齐，使得在打印后也可以易于阅读。
缩进的注释。
注释不应该截断代码，或者打乱逻辑流程。
让注释的缩进位置和周围的代码保持一致。
行尾注释。
在注视和代码之间保留空白是一种好习惯。
帮助你阅读代码。
通常注释在它描述的代码的上方，而不是下方。
选择一种维护成本较低的风格。
在美观的源代码和维护成本之间，总是存在一种平衡，与得到丑陋的代码相比，我更倾向于在维护上花一些时间。
分隔板。
如果你的函数太大，以至于你需要一些视觉上的线索来提示函数的开头和结尾，那么你应当修改你的代码。
标志。
注释还可以用作代码中内嵌的标志。
文件头注释。
所有的源文件都应该一描述其内容的注释块作为开头，其中应该包含的信息是文件的目的和描述所有权及版权信息的版权声明。
头注释中不应该包含容易过时的信息，也不需要包含描述每次都做了哪些修改的源文件历史记录。
编写注释的两种方式：
首先用注释构造代码的结构，然后在各行注释下面填写代码。
首先徒手编写新的代码，然后添加必要的注释。
有经验的程序员会编写代码边写注释。
实践会告诉你使用多少注释是正确的。
在错误得到修正的地方放置一个通告是一种常见的但是存在争议的注释习惯。
在作出不明显的修改时是否应该添加注释，以防止别人在日后修改代码时又引入新的错误，对这个问题仍然存在着争论。
注释会过时的，所有粗心维护的代码都会过时，从而招致很多难看的缺陷，并且失去原本整洁的设计。
注释过时的速度似乎比任何其他代码过时的速度都要快，他们会随着他们所描述的代码一起过时。
当你修正、添加或者修改任何代码时，修正、添加或修改周围的相关注释。
我们必须让注释足够简单以便于更新，否则它们很容易过时。
如果你发现一段注释确实不正确或有误导作用，那么你应当把修改这段注释作为你的代码维护工作的一部分。
注释不会比它们所标注的代码更重要——你无法使用注释把糟糕的代码变好，你的目标应该是编写根本无需注释的自文档化的代码。
优秀的程序员：
1.尽量只写少量的好注释；2.编写解释为什么的注释；3.集中精力编写优秀的代码，而不是过多的注释；4.编写有意义。
有帮助的注释。
糟糕的程序员：
1.不能说出好的注释和差的注释之间的差异；2.编写解释如何做的注释；3.并不介意注释只是对他们自己有意义；4.使用许多注释来支持糟糕的代码；5.用多余的信息来填充源文件。
第六章人非圣贤
错误可能而且必将发生。
几乎任何操作都会带来意想不到的结果，这种结果与有缺陷的程序中的bug不一样，因为你预先就知道错误会发生。
如果你不编写代码来处理这些错误情况，那么你几乎肯定最终会遇到bug；你的程序不会总按你的意愿执行。
错误产生得原因可以分为以下三种：
用户错误。
一个好的程序会指出错误所在，并帮助用户来改正它。
程序员错误。
由程序员引入的代码缺陷。
意外情况。
我们需要一个定义良好的策略来应对我们代码中的各种错误。
不论是由人来选择怎么处理问题，还是由代码来决定——一定要由某人或者代码来负责确认错误和对错误作出反应。
错误由下层组件提出并向上传播，以便让调用方来处理。
错误以什么方式提出，称为错误报告机制，可以分为以下几种：
不报告。
这是最简单的情况。
绝对不要忽视任何一种情况，如果你不知道如何处理这个问题，就向调用代码发送一个故障信号，不要对错误心存侥幸。
返回值。
从函数返回一个表示成功或者失败的值，一个更高级的方法是列举出所有可能的退出状态，并返回一个相应的原因代码，一个值表示成功，其余的值分别代表许多不同的异常终止信息。
错误状态变量。
这种方法试图解决函数的返回值和它的错误状态报告之间的矛盾。
函数将设置一个共享的全局错误变量，而不是返回一个原因代码。
但是这种方法在多线程时会很麻烦。
从功能上讲，这种技术与使用返回值是等价的，但是它的缺陷之多足够让你放弃使用。
异常。
异常是一种管理错误的语言工具；不是所有的语言都支持异常。
异常是不能被忽略的，如果没有被捕获和处理，异常就会传播到调用堆栈的最高层，这通常会导致程序崩溃，这使得异常相对于手工编写的错误处理代码来说更加整洁和安全。
处理一个异常的代码与引发该异常的代码截然不同，而且可以差的很远；异常并非没有开销，语言对异常的支持会造成性能上的损失。
信号。
它是一种更加极端的报告机制，主要用于由执行环境向运行程序报告错误，信号是硬件中断的软件等价物。
有恢复能力的代码一定是针对异常安全的，不论出现什么异常，它都必须正确的运行。
异常中立的代码将所有的异常都传播到调用方，它不会隐藏或者改变任何东西。
异常安全分为以下3个等级：
1.基本保证，如果异常在一个函数中发生，它将不会泄露资源，代码的状态将保持连贯，但是它不一定会保持一种已知的状态；2.强力保证，如果通过你的代码传播了一个异常，程序的状态将保持完全不变；3.不抛出保证，操作永远不能抛出异常，如果我们是异常中立的，那么就意味着函数不能执行任何可能会抛出异常的操作。
根据不同的错误报告机制，我们有不同的检测错误的方式：
返回值。
错误状态变量。
异常。
只有在知道可能会抛出异常的情况下，你才能作出明智的选择，而只有这已被文档化的情况下，你才能够知晓。
信号。
需要为其安装一个处理程序。
在对一个错误进行处理前，我们需要了解错误相关的一些关键信息：
错误来自何处。
当时的上下文环境。
为什么会出错。
错误是何时发生的。
错误的严重性。
如何修正错误。
我们在何时处理错误，可以分成两派：
1.尽可能早的处理，因为错误是在其来源附近处理的，所以你可以留住重要的上下文信息，从而使得你的代码更加清晰，对于返回错误代码的函数来说通常是最佳的选择；2.尽可能推迟处理，因为检测到错误的代码很少知道应该怎样进行处理，如何处理通常取决于错误出现的环境，即调用环境，异常对于这种处理方式很适合。
我们在修正错误时可能会用到的技巧：
1.日志，日志的作用是记录程序的生命周期中值得注意的事件，以使你可以深入研究程序内部工作方式和执行的重构路径；2.报告，程序应该只在已没有什么可作的情况下才向用户报告错误；3.传播，如果你的代码遇到了一个错误并且不知道该怎么办，那么就把错误向上传，很可能你的调用方有能力解决这
升级会员 