在开始这一节的内容之前，我想先阐明两个在很多时候被混淆的概念，那就是异常 (exception) 和错误 (error)。 在 Objective-C 开发中，异常往往是由程序员的错误导致的 app 无法继续运行，比如我们向一个无法响应某个消息的 NSObject 对象发送了这个消息，会得到 NSInvalidArgumentException 的异常，并告诉我们 "unrecognized selector sent to instance"；比如我们使用一个超过数组元素数量的下标来试图访问 NSArray 的元素时，会得到 NSRangeException。类似由于这样所导致的程序无法运行的问题应该在开发阶段就被全部解决，而不应当出现在实际的产品中。相对来说，由 NSError 代表的错误更多地是指那些“合理的”，在用户使用 app 中可能遇到的情况：比如登陆时用户名密码验证不匹配，

     互联网项目里边，SQL注入漏洞、XSS漏洞和猜测URL攻击这三个漏洞可谓历史悠久，然而直到今天还有人不断中枪，也真是微醺。 这几个漏洞说大也大，说小也小。说大是说这些漏洞危害大，会导致数据层面的安全问题；说小是从技术层面上讲都是未对外部输入做处理导致的，想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。

    虽然Oracle数据库的故障千奇百怪，甚至让客户有种防不胜防的感觉，但还是有很多故障是比较常见的，这些问题也是我们Oracle服务部门在客户现场经常遇见，也经常处理的问题。 事实上，针对这些常见问题，Oracle公司不仅提供了诊断和解决问题的思路和方式，甚至针对具体问题，提供了专门的官方处理文档。如果我们能在平日的运行维护工作中，提前预读这些文档，甚至自己编写相应的故障处理手册，一旦这些常见故障真正发生时，我们就不会那么手足无措，即便不一定完全胸有成竹，也至少可以做到一定的心中有数了，就像打仗一定要有作战预案、一定要打有准备之战一样。 本章就将介绍这些常见故障的诊断和处理过程。例如ORA-00600、内存不够、数据库空间不够、snapshot too old、UNDO表空间无法扩展等。

    人非圣贤孰能无过，对于用户来说，出错行为在所难免，因此在忽略犯错动机的前提下(主要是避免部分极端用户的主观试错)，需要设计师为产品的可用性提供“退路”或者“其他路线”。换句话说，当用户在操作过程中触发了错误事件，需要有合理的交互反馈来帮助用户排除使用障碍，继续未完成的操作——回归到WEB产品本身，即提供“返回入口”和“文案提示”，确保用户能“转移”到正确的操作流程中去。

    人非圣贤孰能无过，对于用户来说，出错行为在所难免，因此在忽略犯错动机的前提下（主要是避免部分极端用户的主观试错），需要设计师为产品的可用性提供“退路”或者“其他路线”。换句话说，当用户在操作过程中触发了错误事件，需要有合理的交互反馈来帮助用户排除使用障碍，继续未完成的操作――回归到WEB产品本身，即提供“返回入口”和“文案提示”，确保用户能“转...