Atitit go语言 golang 艾提拉总结特性优缺点 目录 1. Go 语言最主要的特性: 1 2. 体积大概100M 1 3. 问题 1 3.1. 编译速度和异常控制怎么样 1 3.2.
Atitit go语言 golang 艾提拉总结特性优缺点
目录
3.5. 缺乏泛型和元编程能力,这个相信做过框架类的玩家应该懂的。 3
- 自动垃圾回收
- 更丰富的内置类型
- 函数多返回值
- 错误处理
- 匿名函数和闭包
- 类型和接口
- 并发编程
- 反射
- 语言交互性
貌似异常控制使用返回值模式不好呀
但是也有一些令人诟病的地方,其中Golang错误处理,"五行代码,三行错误处理"。那么怎么正确的处理和对待Golang错误处理机制呢?今天虫虫就和大家一起来说说Golang的错误处理。
在Golang错误处理中,变量名称err遍布各处。不论Golang项目有多大和多重要,普遍的格式化错误结构如下
编程语言都有"正常"的错误处理。为什么我应该使用这个奇葩垃圾的错误处理呢?
在Go语言中处理错误的基本模式是:函数通常返回多个值,其中最后一个值是error类型,用于表示错误类型极其描述;调用者每次调用完一个函数,都需要检查这个error并进行相应的错误处理:if err != nil { /*这种代码写多了不想吐么*/ }。此模式跟C语言那种很原始的错误处理相比如出一辙,并无实质性改进。实际应用中很容易形成多层嵌套的if else语句,可以想一想这个编码场景:先判断文件是否存在,如果存在则打开文件,如果打开成功则读取文件,如果读取成功再写入一段数据,最后关闭文件,别忘了还要处理每一步骤中出现错误的情况,这代码写出来得有多变态、多丑陋?实践中普遍的做法是,判断操作出错后提前return,以避免多层花括号嵌套,但这么做的后果是,许多错误处理代码被放在前面突出的位置,常规的处理逻辑反而被掩埋到后面去了,代码可读性极差。而且,error对象的标准接口只能返回一个错误文本,有时候调用者为了区分不同的错误类型,甚至需要解析该文本。除此之外,你只能手工强制转换error类型到特定子类型(静态类型的优势没了)。至于panic - recover机制,致命的缺陷是不能跨越库的边界使用,注定是一个半成品,最多只能在自己的pkg里面玩一玩。Java的异常处理虽然也有自身的问题(比如Checked Exceptions),但总体上还是比Go的错误处理高明很多。
Go编译器不允许存在被未被使用的变量和多余的import,如果存在,必然导致编译错误。但是现实情况是,在代码编写、重构、调试过程中,例如,临时性的注释掉一行代码,很容易就会导致同时出现未使用的变量和多余的import,直接编译错误了,你必须相应的把变量定义注释掉,再翻页回到文件首部把多余的import也注释掉,……等事情办完了,想把刚才注释的代码找回来,又要好几个麻烦的步骤。还有一个让人蛋疼的问题,编写数据库相关的代码时,如果你import某数据库驱动的pkg,它编译给你报错,说不需要import这个未被使用的pkg;但如果你听信编译器的话删掉该import,编译是通过了,运行时必然报错,说找不到数据库驱动;你看看程序员被折腾的两边不是人,最后不得不请出大神:`import _`。对待这种问题,一个比较好的解决方案是,视其为编译警告而非编译错误。但是Go语言开发者很固执,不容许这种折中方案。
由于Go语言缺乏泛型和继承,而只能使用的类似ruby的brought/mixin来extend class导致go不太适合写业务逻辑,特别是多人合作开发业务逻辑。还是会写到处写不利于维护的重复代码。
其主要有以下几个方面的痛点:
· 编译慢
· 失控的依赖
· 每个工程师只是用了一个语言里面的一部分
· 程序难以维护(可读性差、文档不清晰等)
LiteIDE 是一款开源、跨平台的轻量级 Go 语言集成开发环境(IDE)。
支持的 操作系统
- Windows x86 (32-bit or 64-bit)
- Linux x86 (32-bit or 64-bit)
下载地址 :http://sourceforge.net/projects/liteide/files/
源码地址 :https://github.com/visualfc/liteide
Eclipse 也是非常常用的开发利器,以下介绍如何使用 Eclipse 来编写 Go 程序。
(9+条消息)Go语言不爽 - yueguanyun的专栏 - CSDN博客.html
(9+条消息)Go语言不爽 - yueguanyun的专栏 - CSDN博客.html