【PHP】何时使用Try Catch(转)

几条建议:
   若是没法处理某个异常,那就不要捕获它。 
   若是捕获了一个异常,请不要胡乱处理它。 
   尽可能在靠近异常被抛出的地方捕获异常。 
   在捕获异常的地方将它记录到日志中,除非您打算将它从新抛出。 
   按照您的异常处理必须多精细来构造您的方法。 
   须要用几种类型的异常就用几种,尤为是对于应用程序异常。
   把低层次的异常封装成层次较高程序员较容易理解的异常。
   尽可能输出形成异常的完整数据
   尽可能捕获具备特定含义的异常:好比SqlException,而不是简单地捕获一个Exception。php

  若是你的程序不是对效率苛求得过度,我建议你宁肯多使用一些异常也是好的。
注意:我说的多使用的意思不是让你所有trycatch起来,而后catch(Exception e)把全部的异常都屏蔽了;而是暂时不考虑trycatch可能带来的效率上的损失,而注重程序的稳定性。
至于如何优化trycatch的使用,慢慢来。就我我的的使用而言,影响其实不是很大。程序员

 

    

1.       不要滥用Try…Catch。通常来讲只在最外层函数上才须要。由于该函数不能将Exception再往外抛了。因此须要Catch住作相应的处理,如显示Error Message。或转化为与调用模块约定好的Error Code。内部函数即便Catch住了Exception,也要往外抛,因此没有必要。api

 

2.       为了使用Finally来保证资源的释放。如:服务器

SqlConnection connection = null;函数

    try工具

    {学习

          connection = new SqlConnection(ConnectionString);优化

          connection.Open();开放源代码

         …调试

    }

   catch (Exception ex)

    {

         throw ex;

    }

    finally

    {

         if (connection != null && connection.State != ConnectionState.Closed)

         {

              connection.Close();

         }

}

对这种状况Catch住的Exception直接往外抛,不作处理。须要注意的是这里使用Try…Catch不是惟一的办法,也可使用using语句来保证资源的释放。

 

3.       为了保证函数有统一的出口。好比一个最外层的函数连续调用了一系列内部子函数,当其中某个子函数出错时, 跳到函数最后退出,对这种状况Catch住的Exception直接吃掉,由于在Try里面已经作了错误处理。如:

public Result OutMostFunction()

    {

        Result result = Result.Success;

 

        try

        {

            try

            {

                SubFunction1();

            }

            catch (Exception ex)

            {               

                result = Result.SubFunction_1_Error;              

                throw ex;

            }

 

            try

            {

                SubFunction2();

            }

            catch (Exception ex)

            {

                result = Result.SubFunction_2_Error;

                throw ex;

            }

 

            try

            {

                SubFunction3();

            }

            catch (Exception ex)

            {

                result = Result.SubFunction_3_Error;

                throw ex;

            }

        }

        catch (Exception ex)

        {           

        }

 

        return result;

    }

 

4.       为了区分程序错误与逻辑错误,须要自定义一个Exception类型。好比一个最外层函数调用一个密码验证子函数,就须要区分是由于密码错误(逻辑错误),仍是在密码验证过程当中程序出现了没有预料到的错误(程序错误)。如:

public class GoOutException : Exception {}

public Result OutMostFunction()

    {

        Result result = Result.Success;

 

        try

        {

            try

            {

                if (!VerifyPassword(password))

                {

                    result = Result.Invalid_Password;

                    throw new GoOutException();

                }

            }

            catch (Exception ex)

            {

                if (!(ex is GoOutException))

                {                   

                    result = Result.General_Error;                   

                }

                throw ex;

            }           

        }

        catch (Exception ex)

        {           

        }

 

         return result;

    }

 

 

 

 

 

 

 

 

 

    1. 何时使用try catch语句模块,是否是没有明确的答案?  
    2.   
    3. 来自网友的回答:try catch是程序语言自己提供的一种异常处理机制,你大多数写的代码都是要调用底层的api,而这些api的做者在开发api时,很清楚api在使用的过程当中会有哪些非正常状况发生,所以他要通知api的调用者,至于对于这种非正常状况怎么处理,就交给了api的调用者。  
    4.   
    5. 你是写代码的,你要调用api,所以你就说api的调用者,你也应该处理api自己存在的非正常状况,那你怎么处理这些非正常情况,这就是你提到的try catch的做用了,它就是干这事的。至于api会有哪些非正常状况发生,须要查api的帮助文档;这些非正常情况怎么处理,这又取决于问题逻辑了,跟实际需求有关系。  
    6. try{A程序块} catch{Exception e}{B程序块} 。。。。。  
    7.   
    8. A程序块比较有可能会出错的地方,B则是若是A中有了错误,进行的处理。就比如,一个流水线上,若是有个地方有个产品堵住了不通了,若是没人处理,则整个流水线就无法动做了,要想保证整个流水线的运做则要有人把这个产品给处理了。try语句就是对A程序块的语句进行捕捉有可能出错的地方,至关于流水线上那个检查的人,catch语句则是处理的.  
    9.   
    10. 什么状况下须要用try-catch呢,那就是不使用这种try结构时,代码报错退出就没法继续执行。有的代码出错就应该退出,有的出错尚能够补救,就不该该退出。对于这种出错不该该退出的就须要使用这种结构,在catch中进行补救。例如,写入一个日志文件,若是这个日志文件被锁定或者占用,那么写入就会出错退出,可是咱们并不想看到这样的状况,咱们彻底能够换一个名字再写入。  
    11.   
    12. 有的函数或者功能调用以后不会出错退出,可是会返回错误码,这个时候也不须要使用try-catch结构。直接根据不一样的错误码进行分类处理就好了。  
    13. 因此不是trycatch使用量的问题,仍是看应用场景,若是确实须要防止异常退出,须要屡次补救,那么再多都是不为过的。  
    14. 还有一个状况要注意,try-catch不是可以解决全部的出错退出,例如php中的segment fault,也就是熟知的段错误,就算是try-catch了也仍是会退出,这个时候须要使用gdb进行调试解决了。  
    15.   
    16. try catch后是否是必定要输出异常信息?或者有没有更好的办法去处理日志信息呢?                                                                                    
    17. 若是每一段程序都try catch后输出日志,会致使日志信息臃肿不堪,没法从日志中读取有用的信息,使得解决问题更加困难。那有没有统一处理日志信息的工具包呢!规划好日志信息,异常信息将更加清晰明了,同时多读日志能够不段优化程序减小异常的发生状况,一举多得何乐而不为!  
    18.   
    19. LOG4J学习  
    20. 定义:Log4j是Apache的一个开放源代码项目,经过使用Log4j,咱们能够控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等;咱们也能够控制每一条日志的输出格式;经过定义每一条日志信息的级别,咱们可以更加细致地控制日志的生成过程。最使人感兴趣的就是,这些能够经过一个配置文件来灵活地进行配置,而不须要修改应用的代码。  
    21. 程序开发环境中的日志记录是由嵌入在程序中以输出一些对开发人员有用信息的语句所组成。例如,跟踪语句(trace),结构转储和常见的 System.out.println或printf调试语句。log4j提供分级方法在程序中嵌入日志记录语句。日志信息具备多种输出格式和多个输出级别。  
    22. 使用一个专门的日志记录包,能够减轻对成千上万的System.out.println语句的维护成本,由于日志记录能够经过配置脚本在运行时得以控制。 log4j维护嵌入在程序代码中的日志记录语句。经过规范日志记录的处理过程,一些人认为应该鼓励更多的使用日志记录而且得到更高程度的效率。  
    23.   
    24. 使用log4j大概涉及3个主要概念:  
    25. 公共类 Logger Logger 负责处理日志记录的大部分操做。  
    26. 公共接口 Appender Appender 负责控制日志记录操做的输出。  
    27. 公共抽象类Layout Layout 负责格式化Appender的输出。
相关文章
相关标签/搜索