阻塞和非阻塞指的是 work thread，如果是异步阻塞的话，需要更多的 work thread 带来的开销更大，而异步非阻塞能使用少量的 work thread 来排队，而 io 线程交给线程池处理，减少开更多线程的切换开销，适合 IO 密集型而非 计算密集型。

@wysnylc 但是我是 rxjs （跑

不过到时候看看 flow 是什么情况，毕竟我也用 Java

@WenhaoWu rxJava 的 catch 和 trycatch 没什么区别，讨论的核心还是要不要 catch。是我 do/tap/map 里面判断掉然后 filter 还是用 throw Error，来进行流程控制。

我感觉会 Rx Java 就没必要参与这个讨论了…Rx Java 本来就是一套流程控制库，充分使用自然知道会使用自己认为更好的策略

@crclz 跟我想法一样。不过 dalao 还是更简练深刻，我讲的废话多…大佬有兴趣看我回复记录就能看见了。


@wysnylc 难怪开了一贴，原来在这里讨论…哈哈哈

@wysnylc 其实我这里也没有聊兼容性和扩展性，这个更多需要依赖业务和经验，可惜我也对这块也不是很熟悉。我工作经验还不是很久。

但是我能充分感受到的是，不用 try catch 最大的原因是因为看了一段代码之后，会开始思考究竟需要再哪个流程 try catch，那个流程怎么进行 try catch。但是往往面临的问题是我自己连 try catch 在哪里都不一定能确定下来

比如 一个 (流程 A) 里面执行了 (方法 B) ，B 执行了 (方法 C) ，A 结束之后执行 (流程 H)，但是这个时候 C 里面 throw 了 error，我需要在 流程 A 里面处理，但是问题是我需要来自 B 的数据。这时候这个代码就写的一塌糊涂。这还是 3 层，如果是 4 层、5 层呢，怎么处理？


@lcdtyph 在运行效率面前我选择工作效率，如果舍弃了 try catch 还出了性能问题，那么已经是无力挽回了。有流程控制还能想办法优化。

@wysnylc 最主要的是问题还是一些人代码写的烂，不懂写过程和重构。（以下只针对不懂怎么写流程的新手）

通俗点说，多少人经历过业务逻辑自己来重构的？比如写一个过程，不少人从开始学习就以自己的角度来定义 interface 或者 private method，然后导致的问题就是自己并不是真正把一套流程看清楚然后编写的，比如一个业务流程被分到两个方法里面（当然，更多的还是流程写一个方法不重构的，偶尔写点 Utils 来处理下重复逻辑）。

再简单点说，一个方法分为业务 /流程代码， 以及数据处理代码。流程代码本来就只需要调用重构后的方法为主和业务判断处理就行了，结果一个方法写的和面条一样。最后连流程都不知道，还祈求这些人能进行流程上的 try catch 这个根本做不到...所以我带人的时候建议他们，别写一些自以为是的封装方法和 interface，写完了流程自己整理一下，然后根据流程重构一下，更别在流程代码里面写一些过长的数据处理。

这点我尤其要批评以 vue 和 angular 的部分前端开发， 一个组件下来连个有 return 都没有，连自己的流程都不清楚，还怎么控制流程，更不可能去做 try catch，做下来根本没法控制，只能引用更多的状态来控制多个方法的操作。本来不需要的东西结果越写越复杂。

所以还是强调我第一句，一些人写代码根本没有流程的概念。没有就多写一些面条方法然后自己多看一眼。怎么重构才对。

前端的话，我建议写方法养成一个习惯，一个只有一个异步调用的代码，分三个阶段，声明主要局部变量和把 this 上的数据 赋值 /浅拷贝 给局部变量，然后中间的所有流程不允许调用 this 上面的 data，然后赋值要等所有的操作再赋值（就像 react ）。
但是比 react 多的步骤是局部变量，原因还是这块的话能对重构友好，首先对 debug 影响少（因为 debug 的时候你总会去看看谁调用了状态），第二是对重构友好，重构瞬间能产生一个没有副作用的 function。这样的话本身写出来的代码能简洁而且极易 debug 和维护。同时如果需要 try catch 也是很容易的。

3. 我并不喜欢。徒增难度而已，很多时候错误处理和 throw 的地方跨了好几个调用栈，你这意味着你每个调用栈都可以需要有处理来自 method 的 response。

我有一个业务是有 http 调用和 sql 调用，还有调用结束之后的 业务报错。 具体是 A -> B -> HTTP, A -> B -> SQL, 这个时候不管是 HTTP 或者 SQL 还是 B 里面业务逻辑，都可能会异常，但是这个异常都必须交给 A 来响应，说实话如果我写了 method response 的话，本身就是给自己增加烦恼，我还要在 B 里面区分 response 然后交给 A，这个流程代码会写的很冗长。

@ps1aniuge 2 年以上难道就没问题？ 2 年以上能找到一个薪资低的也不容易。

@loliyu 然而唤醒率还不咋样...非常智障

@fpure 这个也是为什么我买 jetbrain 全家桶的理由而不是单个 idea ultimate， 有的人问 idea 不是都能做吗... 问题无关插件都怼上来的时候，占空间还占快捷键。

jetbrain 多个语言多种 ide，虽然功能有相互交叉的，但是 workspace 基本都是不一样的。如果 vscode 出了这个功能我感觉会更受欢迎，就像当初 eclipse 各种被魔改成某种特殊 ide 一样，但是 vscode 的插件安装来的更为方便和直观，小工作量开发还是能顶上去的。

现在 vscode 缺乏一个自定义 workspace 然后分开来打开的功能...所有的语言插件丢一起，我有点受不了。

另外就算是前端，其实 webstorm 比 vscode 强多了... 不过 vscode 免费，只能说 vscode 在 web 开发上的体验接近于 webstorm，其他的还远。

不过 remote 真香，到时候试试看看 java remote 开发

网速继续提高，带来的成本是增加的，因为基建并没有得到充分的发展，大家只会越来越卡。这一波上 1000m 光纤很有跃进的想法。可以做，但是很勉强，当然，其实国内用 onedrive for business 是不会太卡的，可以考虑一下（不是 office 365 那个

公司电脑 Linux， 自己电脑 Windows，然后一起用…平时跑服务，远程 vs code 开发都行

@lizhuoli flutter 的底层我感觉看着真的不错…比 Web 强多了。很多实现方面 Web 根本不接触。


另外说一下…微信里面也用了 flutter，至少这样的重量级生态也选择 flutter，我感觉没问题

@acreti #40 然而 阿里 dns 解析到了 210 开头的了
> nslookup pixiv.net 223.5.5.5
服务器: public1.alidns.com
Address: 223.5.5.5

非权威应答:
名称: pixiv.net
Addresses: 210.140.131.219
210.140.131.222
210.140.131.224


> nslookup pixiv.net 8.8.8.8
服务器: dns.google
Address: 8.8.8.8

非权威应答:
名称: pixiv.net
Addresses: 210.140.131.224
210.140.131.222
210.140.131.219

呵呵， 我最近的响应速度慢不说，我住的群居房地区，强制限速不超过 1m/S 换个地区就可以，别跟我说什么人太多，我测速的时候速度第一秒上了 50m，然后急剧下降。

首先信息太少
第二，我 ryzen 2700 直接运行 ubuntu 没有任何异常

你可以去阿里云或者腾讯云薅个主机来用。会比你安装 vmware 来得好用

@chairuosen #7 这个是用 volumn 挂载数据进去的，很容易，也不需要管依赖，平时也一样用。