1.异常规范的使用场景是,承诺方法只抛出什么样的异常,或者不抛出异常.如果运行的时候,不满足承诺,C++自动调用unexpected方法,unexpected调用terminate方法,terminate调用abort方法结束程序. 2.有三点需要注意:a.表面上不抛出任何异常,仔细分析还是可能会抛出异常:b.调用其他的方法,而其他的方法可能抛出异常:c.调用系统的方法,系统方法可能抛出异常.因此,承诺只抛出某些异常,或者不抛出异常(异常规范),基本上不太靠谱. 3.如果抛出了,非预期的异常.默…

把异常的栈轨迹以String形式返回 /** * 把异常的栈轨迹以String形式返回,而不是直接打印到console * @author King * @time 2015-04-29 * @return */ public static String getLongInfo(Throwable e){ StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw, true); e.printStackTr…

1. 只针对异常情况使用异常,不要用异常来控制流程 try { int i = 0; while (true) { range[i++].doSomething(); } } catch (ArrayIndexOutOfBoundsException e) { // ... } 说明: 1) 上述反例企图通过捕获异常来结束无限循环,以此达到遍历数组的目的.不要这么做! 2) 异常机制本身设计为处理异常情况,用异常来实现正常控制流,会阻止 JVM 本来可能要执行的某些特定优化,从而导致代码效率变低…

Atitit 数据处理查询 中的异常标准化草案 jpa jdbc hb  oql规范attilax总结 Javaee6 与net 异常规范1 Jpa规范 JPA全称Java Persistence API.1 Jdbc api1 Hibernate api1 Javaee6 与net 异常规范 Jpa规范 from jee6 Jpa规范 JPA全称Java Persistence API. package javax.persistence; NonUniqueResultException N…

异常规范 异常规范的理念看似有前途,但实际的使用效果并不好. 忽视异常规范之前,您至少应该知道它是什么样的,如下所示: double harm(double a) throw(bad_thing);  //may throw bad_thing exception double harm(double a) throw();    //doesn't throw an exception 其中throw()部分就是异常规范,它可能出现在函数原型和函数定义中,可包含类型列表,也可不包含. 异常规范…

转载:http://dsqiu.iteye.com/blog/1688217 组织和策略问题 0. 不要为小事斤斤计较.(或者说是:知道什么东西不需要标准化) 无需在多个项目或者整个公司范围内强制实施一致的编码格式.只要规定需要规定的事情:不要强制施加个人的喜好或者过时的做法. C++不应该使用匈牙利命名法.在有智能指针的情况下,单入口单出口可能不是必须的.代码要有自注释性. 1. 在高警告级别下干净地编译代码. 要把警告放在心上:使用你的编译器的最高警告级别.要求干净(没有警告)的构建.理解所…

这是一本好书, 可以让你认清自己对C++的掌握程度.看完之后,给自己打分,我对C++了解多少? 答案是不足20分.对于我自己是理所当然的问题, 就不提了, 记一些有启发的条目和细节: (*号表示不能完全理解,实力升级了之后回头看) 一般性问题: 1. 不要在注释中重复写代码语义,这样很容易产生不一致. 应该编写的是解释方法和原理的说明性注释. 2. 不要对每个项目每个文件进行强制的排版格式规定, 在同一个文件中风格一致即可. 3. 匈牙利记法是混用了类型不安全语言中的设施, 在面向对象语言中可以…

这是一本好书, 可以让你认清自己对C++的掌握程度. 看完之后,给自己打分,我对C++了解多少? 答案是不足20分. 对于我自己是理所当然的问题, 就不提了, 记一些有启发的条目和细节: (*号表示不能完全理解,实力升级了之后回头看) 一般性问题: 1. 不要在注释中重复写代码语义,这样很容易产生不一致. 应该编写的是解释方法和原理的说明性注释. 2. 不要对每个项目每个文件进行强制的排版格式规定, 在同一个文件中风格一致即可. 3. 匈牙利记法是混用了类型不安全语言中的设施, 在面向对象语言中…

组织和策略问题 第0条 不要拘泥于小节(又名:了解哪些东西不应该标准化) 第1条 在高警告级别干净利落地进行编译 第2条 使用自动构建系统 第3条 使用版本控制系统 第4条 在代码审查上投入 设计风格 第5条 一个实体应该只有一个紧凑的职责 第6条 正确.简单和清晰第一 第7条 编程中应知道何时和如何考虑可伸缩性 第8条 不要进行不成熟的优化 第9条 不要进行不成熟的劣化 第10条 尽量减少全局和共享数据 第11条 隐藏信息 第12条 懂得何时和如何进行并发性编程 第13条 确保资源为对象所拥有…

<C+编程规范 101条规则.准则与最佳实践> 0.不要拘泥于小节(了解哪些东西不应该标准化) * 与组织内现有编码规范一致即可 * 包括但不限于: - 缩进 - 行长度 - 命名规范 - 注释形式 - 空格/制表符 1.在高警告级别干净利落地进行编译 * 使用编译器的最高警告级别,构建完应用程序后应该是0警告. 理解所有的警告,通过修改代码而不是降低警告级别来消除警告. * VS警告级别: - /W0 关闭所有警告 - /W1 显示严重警告 - /W2 显示等级1以及某些不太严重的警告 -…