Golang中异常处理机制详解

前言

通常我们需要编写好的错误处理方式，在了避免某些程序员滥用异常，于是Go这里直接把异常这一块给砍掉了，最终还是通过返回值来判断程序的异常情况，毕竟Go可是支持多返回值的语言，比如atoi、itoa等函数，就不能忽略它的第二个返回值，因为第二个返回值代表了转换是否成功！不过Golang还是提供了一些错误处理机制的

Go的错误机制

1、没有异常机制

2、error类型实现了error接口

3、可以通过errors.New来快速创建错误实例

type error interface{
    Error() string
}

error.New("n must be in range[0, 1]")

但是这样做只是给开发者标识，Code怎么认识呢？难道去string里判断吗？当然不是，可以预定义一些错误：

处理错误最佳实践

1、预定义错误，code里判断

2、及早失败，避免嵌套

panic与recover

panic用于不可恢复的错误，类似于Java的Error
panic退出前会执行defer指定的内容

panic和os.Exit
os.Exit退出时不会调用defer指定的函数
os.Exit退出时不会输出当前调用栈信息

接下来看看recover

在Java中如果你不知道要抛出什么错误，于是乎很多人直接来个Catch Throwable，作为一个异常无Fack说，C++中是直接catch…作为一个异常无Fack说

在Go语言中可以通过defer定义的函数去执行一些错误恢复的行为

很多人容易在defer处理错误时把recover获得的错误对象打印到日志文件中，这是一种非常危险的做法，一定要当心recover在做的事情，因为recover的时候并不去检测到底发生了什么错误，而是直接忽略了这个错误，那么如果这个时候系统的核心资源消耗完了，如果我们强制性的恢复的话系统仍然是不能正常工作的，还会导致我们的健康检查程序没办法检查出当前系统的问题，因为很多的health check只是检查进程在还是不在，因为我们的进程是在的，所以会导致僵尸服务进程，虽然活着但是无法正常提供服务。于是我们可以采用恢复设计模式中的一种叫做Let it Crash ，health check进程就会帮我们重启这个服务

总结

到此这篇关于Golang中异常处理机制的文章就介绍到这了,更多相关Golang异常处理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • 深入理解golang的异常处理机制

    前言 众所周知在java或php等很多面向对象的语言中, 异常处理是依靠throw.catch来进行的.在go语言中,panic和recover函数在作用层面分别对等throw和catch语句,当然也存在不同之处.下面话不多说,来一起看看详细的介绍吧. 从设计层面来看,panic和recover函数适用于那些真正的异常(例如整数除0),而throw catch finally机制常常被用来处理一些业务层面的自定义异常.因此在go语言中,panic和recover要慎用. 上述两种异常机制的使用中

  • Golang中异常处理机制详解

    Golang中异常处理机制详解

    前言 通常我们需要编写好的错误处理方式,在了避免某些程序员滥用异常,于是Go这里直接把异常这一块给砍掉了,最终还是通过返回值来判断程序的异常情况,毕竟Go可是支持多返回值的语言,比如atoi.itoa等函数,就不能忽略它的第二个返回值,因为第二个返回值代表了转换是否成功!不过Golang还是提供了一些错误处理机制的 Go的错误机制 1.没有异常机制 2.error类型实现了error接口 3.可以通过errors.New来快速创建错误实例 type error interface{ Error(

  • C++11中异常处理机制详解

    目录 一.异常的引入 二.C++异常的关键字 三.异常的抛出与处理规则 四.异常缺陷的处理 五.自定义异常体系 六.异常规范 七.异常安全 八.异常的优缺点 1.优点 2.缺点 一.异常的引入 传统的C语言处理异常的方式有两种: 1.终止程序:使用assert断言语句,如果发生内存错误等,比如内存泄漏或者除0错误,都会直接终止程序. 2.返回错误码:通过错误码判断发生的异常的类型是什么,如系统的很多库的接口程序通过把错误码放到errno中,表示错误. 在实际中的C语言程序基本都是通过返回错误码的

  • java-流的使用完结与异常处理机制(详解)

    1.1 java.io.objectInputStream 对象输入流:用于将一组字节(通过对象输出流写出对象而转换的一组字节)读取并转换为对应的对象.对象输出流将对象写出时转换为一组字节的过程,称为:对象序列化对象输入流将这组字节读取并还原会对象的过程,称为:对象反序列化 1.2 java.io.Serializable Serializable序列化接口 当一个类实现了Serializable接口后,应当在当前类中添加一个常量: 序列化版本号serialVersionUID 序列化版本号若不

  • Java try-catch-finally异常处理机制详解

    Java try-catch-finally异常处理机制详解

    Java中的try-catch-finally异常处理 一.异常处理 异常(Exception):是在运行发生的不正常情况. 原始异常处理: if(条件) { 处理办法1 处理办法2 处理办法3 } if(条件) { 处理办法4 处理办法5 处理办法6 } 代码阅读性差,臃肿不堪,与正常流程代码结合的很紧密,所以,在JAVA中进行一系列的改良,将一系列常见的问题,用面向对象的思考方式,对其进行了描述.封装. class 处理办法 { 处理办法1() { 举例1 } 处理办法2() { 举例2 }

  • Java SpringMVC拦截器与异常处理机制详解分析

    Java SpringMVC拦截器与异常处理机制详解分析

    目录 拦截器(interceptor)的作用 拦截器快速入门 案例:用户登录权限控制 拦截器方法说明 SpringMVC异常处理 异常处理的思路 异常处理两种方式 拦截器(interceptor)的作用 Spring MVC的拦截器类似于Servlet开发中的过滤器Filter,用于对处理器进行预处理和后处理. 将拦截器按一定的顺序联结成一条链,这条链称为拦截器链(Interceptor Chain).在访问被拦截的方法或字段时,拦截器链中的拦截器就会按其之前定义的顺序被调用.拦截器也是AOP思

  • SpringMVC项目异常处理机制详解

    目录 1.异常分类 2.自定义项目业务异常 3.自定义项目系统异常 4.其他异常 5.异常代码 6.异常处理器 7.异常发生 1.异常分类 通常分为三类:系统异常(SystemException),业务异常(BusinessException)和其他异常(Exception) 业务异常指由于用户的不规范操作产生的异常,如不合法的参数传入 系统异常指项目运行过程中可预计但无法避免的异常,如数据库宕机 其他异常指开发者未曾预料到的异常 2.自定义项目业务异常 public class Busines

  • C++中的异常处理机制详解

    异常处理 增强错误恢复能力是提高代码健壮性的最有力的途径之一,C语言中采用的错误处理方法被认为是紧耦合的,函数的使用者必须在非常靠近函数调用的地方编写错误处理代码,这样会使得其变得笨拙和难以使用.C++中引入了异常处理机制,这是C++的主要特征之一,是考虑问题和处理错误的一种更好的方式.使用错误处理可以带来一些优点,如下: 错误处理代码的编写不再冗长乏味,并且不再和正常的代码混合在一起,程序员只需要编写希望产生的代码,然后在后面某个单独的区段里编写处理错误的嗲吗.多次调用同一个函数,则只需要某个

  • Android中Intent机制详解及示例总结(总结篇)

    Android中Intent机制详解及示例总结(总结篇)

    最近在进行android开发过程中,在将 Intent传递给调用的组件并完成组件的调用时遇到点困难,并且之前对Intent的学习也是一知半解,最近特意为此拿出一些时间,对Intent部分进行了系统的学习并进行了部分实践,下面将自己的学习及Intent知识进行了详细的归纳整理,希望能帮助到同样遇到相同问题的博友. 下面是Intent介绍.详解及Intent示例总结: 一.Intent介绍: Intent的中文意思是"意图,意向",在Android中提供了Intent机制来协助应用间的交互

  • Golang中的Interface详解

    Golang中的Interface详解

    背景: golang的interface是一种satisfied式的.A类只要实现了IA interface定义的方法,A就satisfied了接口IA.更抽象一层,如果某些设计上需要一些更抽象的共性,比如print各类型,这时需要使用reflect机制,reflect实质上就是将interface的实现暴露了一部分给应用代码.要理解reflect,需要深入了解interface.go的interface是一种隐式的interface,但golang的类型是编译阶段定的,是static的,如:

  • node.js中watch机制详解

    几乎所有构建系统都选择使用watch机制来解决开发过程中需要反复生成构建后文件的问题,但在watch机制下,长期以来我们必须忍受修改完代码,保存完代码必须喝口茶才能刷新看看效果的问题.在这里我们尝试探讨为什么watch不是银弹,并尝试寻找一种更好的方案来解决这个问题. watch基于的事实 当一个文件修改,我们能知道其修改可能导致的文件修改,那么重新构建这些文件即可. 通常对于文件A,构建成文件B这种场景,这种对应关系是极好确定的.但现实场景下,构建过程往往不是那么简单.例如: 文件A + 文件

随机推荐