runtime

之前在用babel 的时候有个地方一直挺晕的， @babel/preset-env 和 @babel/plugin-transform-runtime 都具有转换语法的能力， 并且都能实现按需 polyfill ,但是网上又找不到比较明确的答案， 趁这次尝试 roullp 的时候试了试. 如果我们什么都不做， 没有为babel 编写参数及配置， 那babel 并没有那么大的威力， 它什么都不会做， 正是因为各个预设插件的灵活组合、赋能， 让 babel 充满魅力， 创造奇迹 首先是 @babel/preset-env @babel/preset-env 这是一个我们很常用的预设， 几乎所有的教程和框架里都会让你配置它， 它的出现取代了 preset-es20** 系列的babel 预设， 你再也不需要繁杂的兼容配置了。 每出一个新提案就加一个？ 太蠢了。 有了它， 我们就可以拥有全部， 并且！ 它还可以做到按需加载我们需要的 polyfill。 就是这么神奇。 但是吧， 它也不是那么自动化的， 如果你要是不会配置，很有可能就没有用起它的功能 不管怎么养， 首先试一下，眼见为实 首先创建一个 index.js ,内容如下， 很简单 function test() { new Promise() } test() const arr = [1,2,3,4].map(item =>

之前在用babel 的时候有个地方一直挺晕的， @babel/preset-env 和 @babel/plugin-transform-runtime 都具有转换语法的能力， 并且都能实现按需 polyfill ,但是网上又找不到比较明确的答案， 趁这次尝试 roullp 的时候试了试. 如果我们什么都不做， 没有为babel 编写参数及配置， 那babel 并没有那么大的威力， 它什么都不会做， 正是因为各个预设插件的灵活组合、赋能， 让 babel 充满魅力， 创造奇迹 首先是 @babel/preset-env @babel/preset-env 这是一个我们很常用的预设， 几乎所有的教程和框架里都会让你配置它， 它的出现取代了 preset-es20** 系列的babel 预设， 你再也不需要繁杂的兼容配置了。 每出一个新提案就加一个？ 太蠢了。 有了它， 我们就可以拥有全部， 并且！ 它还可以做到按需加载我们需要的 polyfill。 就是这么神奇。 但是吧， 它也不是那么自动化的， 如果你要是不会配置，很有可能就没有用起它的功能 不管怎么养， 首先试一下，眼见为实 首先创建一个 index.js ,内容如下， 很简单 function test() { new Promise() } test() const arr = [1,2,3,4].map(item =>

The following code does compile, but why do I get a run time exception? String b = null; System.out.println(b.getClass()); Error I get is java.lang.NullPointerException How can I get the type of the object even if it's set to null? Edit I realize there is no object present, but there still is an object b of type String. Even if it holds no object, it still has a type. How do I get at the type of an object, regardless of if it holds an object or if it does not. When you have String b = null; what you actually have is a variable of reference type String that is referencing null . You cannot

在程序开发时我们都会认为外部提供的接口或者数据都是不可信的。比如函数总是要检查入参的正确性，在做单元测试的时候要把外部提供的接口给屏蔽掉等。之所以都会这么做，主要还是很难保证自己还是其他人可以提供一个没有任何缺陷的接口。既然接口是人写的，那么多少会有些考虑不到的地方，这时候接口在被调用的时候就有可能发生错误或者异常。这里讨论golang中的异常处理机制，其实就是panic和recover这两个接口的运用，类似于C++中的try和catch。 1、golang中的panic panic，中文解释为恐慌。举个例子，单代码中出现这样的语句的时候，相信所有开发人员在产品上线的时候都会恐慌： var MakecoreData * int = nil *MakecoreData = 10000 如果不做任何处理的时候，这个golang出现如果跑到这里的时候就会出现这样的结果。 panic: runtime error : invalid memory address or nil pointer dereference [signal 0xc0000005 code= 0x1 addr= 0x0 pc= 0x5d0676 ] 然后重新就退出了，这个结果其实跟C/C++中的core是一样的。 当然这个例子可能不会有人会犯这种低级错误，但是如果这两个语句中间加上一段复制的逻辑

golang当中panic的时候如果启动的goroutine比较多，刷的信息满屏都是，在终端工具上因为刷的信息太多，找不到前边的信息，因此很有必要程序自己捕获panic，并且将错误信息输出到文件当中，以便定位排查问题。 以下是一段捕获panic的代码 package main import ( "fmt" "os" "runtime/debug" "time" ) func PanicHandler() { exeName := os.Args [0 ] //获取程序名称 now := time.Now() //获取当前时间 pid := os.Getpid() //获取进程ID time_str := now.Format( "20060102150405" ) //设定时间格式 fname := fmt.Sprintf( "%s-%d-%s-dump.log" , exeName, pid, time_str) //保存错误信息文件名:程序名-进程ID-当前时间（年月日时分秒） fmt.Println( "dump to file " , fname) f, err := os.Create(fname) if err != nil { return } defer f.Close() if err := recover (); err != nil { f

一. 缘起 程序进程后台运行 monitor 监控程序负责拉起程序 当因为逻辑问题导致后台进程挂掉时，不容易发现程序曾经挂过。 golang 可以通过 recover 捕获 error，并将 panic 时的堆栈打印到日志来定位问题。 $ tree panictest panictest ├── main. go └── panic └── panic . go 二. 代码 main.go package main import ( "fmt" "os" "./panic" ) func test() { defer func () { if e := recover (); e != nil { panic .PrintStack() os.Exit (1 ) } }() zero := 0 x := 3 / zero fmt.Println( "x=" , x) } func main() { test() } panic.go package panic import ( "fmt" "runtime" ) func PrintStack() { var buf [4096 ] byte n := runtime.Stack(buf[:], false ) fmt.Printf( "==> %s\n" , string (buf[:n])) } 三. 运行结果 $ go