@noli 按照例子，你说要对不同的错误做针对的处理，那么无论如何避免不了 switch ，只是以各种不同的 exception 表现而已。

对于错误的检查，如果忽略，确实会存在问题，错误会一层层的传递而不处理。
defer 在 Golang 共识是不能滥用，这和不处理 exception 一样的道理。

Golang 的一些设计，不是说刻意这么做，开发者自己说了，“没想好怎么做”
以后 Golang 语言层面如果有什么变化，也不奇怪。

我有很长的 Java, Python, 和半年 Golang 经验，但是在 Exception vs Error as Value 比较中，我自己也想不出什么合适，只能从语言 taste 来理解。

对于大型开发中，可能需要引入自己的 error list ，比如
https://github.com/go-sql-driver/mysql/blob/master/errors.go 的 MySQLError
然后和 mysql error number 做对应，调用的时候决定错误类型已经怎么处理。

golang 的 error 目前是我比较困惑的地方，因为迫使你不得不认真的思考错误处理，否则容易漏掉。

@noli 我看了你的代码是在 exception 做 switch ，实际上，这和 Golang 的 err 设计类似的，
你可以理解 Golang 里面的 err 就是枚举，对应一个个的 exception
对于 network 的 error ， golang 的开发者只是做的比较简单，比如 net package 的 error ：

var (
// For connection setup and write operations.
errMissingAddress = errors.New("missing address")

// For both read and write operations.
errTimeout error = &timeoutError{}
errCanceled = errors.New("operation was canceled")
errClosing = errors.New("use of closed network connection")
ErrWriteToConnected = errors.New("use of WriteTo with pre-connected connection")
)
也许还有其他几种错误。

所以按照刚才 @goool 的代码，在 channel 的遍历阶段，把 error 做 switch 决定是否算错误就可以了。
但实际上，单纯从你们写的这两代码来看，我觉得， Golang 显然容易理解多了。
我阅读一些开源代码，确实是存在需要关注指定 error ，而不得不使用 string match 的方式来匹配。是比较难看的方式，但这是可以改进的。

但是从我以前 Java 的经验来看， Exception 改变了程序流程的运行是一个很大的问题。

其实我觉得这个没有什么问题。
如果要强制 unique ，需要在数据库做一下主键限制

我想问一下 mqtt 用在哪里？

这个人是在透支自己的信用啊

git status|grep modified|grep java$|awk '{print $NF}'|xargs git add

sortedset

@sun2920989 the way to go 很不错。
umeng_devicetoken=MySQLdb.escape_string(web.utf8(data.get('umeng_devicetoken','')))

这段话看起来是使用了 sql escape_string ？
data.get('umeng_devicetoken','') 是 http 的 GET 获取参数？
然后使用 utf8 变成字符？

建议你还是一步步学起来吧

```go
package main

func main() {
b := make([][]byte, 3000000)
for i := 0; i < 3000000; i++ {
buffer := make([]byte, 1024)
copy(buffer, []byte("abcd"))
b[i] = buffer
}
}
```

你这个例子来说几乎是无解的，因为无论如何变量会被引用到，所以 GC 本身不会回收的，哪怕使用 sync.Pool ，这种情况下和 GC 关系不大，哪怕你使用 Java ，一样遇到这个问题。

** 所以你的问题是，如何能够更加“紧凑”的使用内存，避免内存碎片。**

按照你的这个例子，那么就是大量的循环里面创造 slice ，但是 slice 很大，而实际存储内容比较小。
“看起来内存很浪费”

解决方法来看：
1 如果使用自己开发的内存池，在大量动态变化情况下，实际上，你就是在实现一个小型的 GC 了。并且不会比使用 sync.Pool 好多少的。
2 借鉴 memcache 的解决方法，申请大的内存块，然后按照长度切片，比如 128b, 256b, 512b, 1k, 2k ，然后根据实际数据做一些 copy 工作。
3 sync.Pool 和 按照长度分片的 buffer 结合起来，基本能实现你的需求了。

节省内存和避免 COPY 是一个矛盾的问题，内存越紧凑，当长度变化时，需要申请新的空间， COPY 数据，反之就是内存越浪费，这是一个权衡的问题。

@dbow 参考我上面提问，我是想知道这个问题是什么，如果你能提供示例代码就更好了。

-- while {readline} 不建内存池这种模式下， 10 亿行文本， 吃内存嗖嗖的, 慢点是没有关系的.

我并不理解你这个需求，如果你能提供更多代码就更好了。因为在 while 里面，最终只是复用一个 slice 而已（当然在超过当前长度的时候会申请新的内存空间）， GC 应该是可控的。
// 使用 *bufio.Reader ReadLine

上面提到的几种方案， sync.Pool ， bytes.Buffer ，有什么理由不能用吗？

@ncisoft 后面的 service db layer 这一块，在各种语言都是类似的，由类似“协程”的概念执行。
也就是说，并没有完全的异步，比如 orm 这一块。
现在多并发的解决方案，都是监听 M 个链接，如果有读写操作，就激发对应的行为，有使用回调也有不用的，不用的你可以理解为语言级别帮你做了。
在 Java 里面，也不是一个链接起一个线程，而是把这个链接的 Context 关联起来，当激发回调方法之后接着进行处理，和线程关系是 M : N 的模型， M 是链接数， N 是线程，其中 M 远远大于 N 。

类似 Golang ，是一种比较激进的做法， Goroutine 是一种非抢占式的运行，直到因为 IO 事件进行切换，所以对线程数需求非常的少。

@ncisoft 如果你单单指的是性能的话， netty 绝不逊于其他各种语言的实现方式。对于 Linux 机器，说到底都是 Epoll 模型。 Netty 基于函数回调，并不是需要依赖于大量的线程。

cat /proc/sys/kernel/random/uuid | md5sum

最最简单的，难道不应该使用 iptables 吗？只把需要的端口开放出来

@anthonyeef 我觉得你的解释不像是，你那种代入感是日本人的方式