我的架构经验系列文章 - 后端架构 - 语言层面

标签：jquery   web前端   框架   ui   前端   

• 运行时元数据获取
  

• 错误处理
  

• 不要把错误的结果吃掉，不要把捕获的异常吃掉。所谓吃掉也就是针对错误结果或异常不做任何的处理，这样就没有人知道这个异常的存在这是很危险的。其实所谓异常就是代码不能执行代码语句本身所隐含的含义，比如有一个方法从名字上看是创建文件的，那么不能创建文件的时候方法应该是要抛出异常的，因为它办不了它应该办的事情，作为类库的编写者应该要这么做，有的时候出了问题我们会很迷茫为什么会出问题，作为类库的使用者应该在这样的方法周围进行异常处理，并且记录这样的异常，那么我们就很容易通过异常信息来找到根源问题，而不是去猜。有的时候根本没办法通过猜来解决问题，因为语言的类库是和操作系统打交道的一首环节，只有类库才知道操作系统有什么问题，比如是因为权限原因不能创建文件还是因为磁盘损坏，如果把这个异常信息舍弃的话是很难知道根本原因的。UI前端框架最新力作！有奖试读！
  
• 具体怎么进行错误处理不能一视同仁需要看情况而定的。并且一般不建议直接捕获最大的异常，能细化的尽量细化，捕获所有异常意味着不能进行处理。一般情况下可以记录日志，或是重新包装后抛出，或是很明确地进行错误处理。
  
• 未处理的异常往往会随着调用栈往上升，升到最上层如果Web服务器发现异常还是未处理的话会导致各种颜色的错误页面。个人认为出现错误页面不一定是坏事情，很多人喜欢把所有的异常都吃掉不出现错误页，这不是解决问题的根本办法，根本办法是找到异常出现的原因，从代码角度解决它，而不是掩耳盗铃。当然，错误页是不应该让终端用户看到的，应该替换成友好的页面，在这个页面上可以什么都不写，也可以写一个异常ID，如果用户觉得这个操作是很要紧的话可以拿这个异常ID来和客服反馈，阐述其操作过程帮助我们解决问题，当然这个大前提是能把所有的异常都记录到数据库或方便查询的文本文件中。很多框架都具有统一收集未处理异常的入口点，在这里我们可以统一把未处理的异常汇总记录。
  

• 垃圾回收
  

• 多线程
  

• 如果多线程同时访问一个资源，比如同时对一个数字进行累加，那么很可能不到达到我们的预期。
  
• 类库所提供的类型不一定都是线程安全的，我们在使用的时候务必要阅读相关的资料确认是不是线程安全的，如果不是那么我们要通过诸如锁之类的手段来确保能够线程安全，否则很可能在调用类库的时候会出现异常或者说不能实现正确的代码。
  
• 多线程的程序调试起来也是比较麻烦的，因为多个线程可能会穿插执行不同的代码，此时我们可以通过记录日志、挂起某些线程或是临时切换为单线程程序来增加代码的调试性。
  
• 我们在编码的时候需要意识到什么是线程，一个线程所消耗的资源有多少，因为不要认为多线程可以提高效率，什么操作都用一堆线程来做，随便开启很多线程，这是得不偿失的，线程虽然比进程的代价小但是代价也不是这么小，因为每一个线程都有一个不小的线程栈，因此如果你发现你的程序开启了上千个线程的话，那么或许要想一下这样是否合理了。
  
• 在开启多线程的时候千万要记得不要遗忘这个线程，不要让线程在哪里什么都不干空循环，对于后台任务类线程，可以在一个地方记录我们程序中开启的线程，对于其它可以结束的线程，要确保线程中的代码能正常结束。
  
• 如果线程中的代码出现异常的话，大多数运行时或虚拟机会认为这是一个比较严重的问题，因为可能会导致整个系统中的状态不能保持一致，比如涉及到钱的系统这就是一个严重问题了，因此对于这种情况宁肯直接终止整个应用程序的进程也不要让这个问题没有人发现，错误的状态得到扩散，如果你觉得线程其实只是做一些无关重要状态的操作的话，务必确保线程不会出现未处理的异常。UI前端框架最新力作！有奖试读！
  

• 代码生成
  

• 动态生成：代码是在程序运行的时候动态生成的，生成的代码在动态编译后动态加载到运行环境中动态执行，这比较适合根据程序的逻辑动态生成一些代码来执行，比如动态生成代理类，代理类的接口如果是事先无法确定的，那么我们也不可能在编译前就生成代码。
  
• 静态生成：一般是在编译前生成，然后直接进行编译的。比如自动根据XML中的相关数据定义生成CRUD的操作代码，既可以避免手写代码，又可以得到和手写代码相同的效率，因为这个代码其实还是死的还是固定的，并不是在运行时动态组织的，因此它的效率是最高的。

我的架构经验系列文章 - 后端架构 - 语言层面

标签：jquery   web前端   框架   ui   前端   

原文地址：http://blog.csdn.net/ariss123/article/details/39371271