g*********9
发帖数: 1285 | 1 Java每个function扔什么Exception，看定义就一目了然，scala怎么就没这个，还得扎
进去看？ |
c******o
发帖数: 1277 | 2 scala可以有和多种做法。。
本身FP不推荐throw exception.
其一， 从来都不throw exception, 用 Try来wrap， http://www.scala-lang.org/api/current/#scala.util.Try
其二， 用 exception util 里的工具来处理 exception, http://www.scala-lang.org/api/current/index.html#scala.util.control.Exception$
其三， 用try/catch/finally来像java一样处理。
你本身不应该记有啥 exception, 只要记函数回复什么正常／不正常之就可以了。要想
debug,log exception
thorw exception本身就不好（打破了function的composability) |
p*****2
发帖数: 21240 | 3 这年头还有拿javs exception拿出来说事的。
【在 g*********9 的大作中提到】
: Java每个function扔什么Exception，看定义就一目了然，scala怎么就没这个，还得扎
: 进去看？
|
z****e
发帖数: 54598 | 4 这个配合aop很好用
不象fp那样，整个一树状结构
aop直接catch到exception，就可以直接分类处理
主流程保持不变，主干和分支分工很明确
你看coltzhao的那个例子里面第一个
分成success和failure，感觉很多时候有些恶心啊
多来几个，2^n种分支，级数增长很快的
关于aop的catch exception，参考这个
http://stackoverflow.com/questions/10947933/aop-exception-handl
【在 p*****2 的大作中提到】
: 这年头还有拿javs exception拿出来说事的。
|
p*****2
发帖数: 21240 | 5 早就说了aop很像monad
【在 z****e 的大作中提到】
: 这个配合aop很好用
: 不象fp那样，整个一树状结构
: aop直接catch到exception，就可以直接分类处理
: 主流程保持不变，主干和分支分工很明确
: 你看coltzhao的那个例子里面第一个
: 分成success和failure，感觉很多时候有些恶心啊
: 多来几个，2^n种分支，级数增长很快的
: 关于aop的catch exception，参考这个
: http://stackoverflow.com/questions/10947933/aop-exception-handl
|
l*******b
发帖数: 2586 | 6 哈哈, java不都是乱扔exception, 一个函数定义四五种exception, try catch 一长串
。只管杀不管埋的么。
其实exception 和内存管理garbage collection 类似。号称解决了所有问题的java,
不过是把问题搬了个地方而已。
【在 p*****2 的大作中提到】
: 这年头还有拿javs exception拿出来说事的。
|
g*****g
发帖数: 34805 | 7 Checked Exception至少帮助你去想想要不要处理一个Exception。举个例子，你在一个
循环里调用一个远程的服务，远程服务没有不出错的。有个Checked Exception你就会
逼你思考一下是要在循环里catch，在循环外catch，在方法上直接抛。三种处理只有一
种是对的。你要是没Checked Exception，可能根本不会注意到这是个远程调用，结果
很可能测试啥的都好，甚至产品上也一直都好，某天网络顿了一下，bug出来了。
fix一个产品上的bug，成本至少是一个fix dev里bug的100倍。Java的这点繁琐，能帮
助你避免很多问题。特别是这年头强调time to market，测试充分很难保证。前端的应
用还好，出这种事情往往只影响到个别用户，重试一下可能也过了。后端可能一个long
running job废了，你半夜被叫起来了。Java在后端这么dominant不是没有理由的。
【在 l*******b 的大作中提到】
: 哈哈, java不都是乱扔exception, 一个函数定义四五种exception, try catch 一长串
: 。只管杀不管埋的么。
: 其实exception 和内存管理garbage collection 类似。号称解决了所有问题的java,
: 不过是把问题搬了个地方而已。
|
l*******b
发帖数: 2586 | 8 远程调用不包装直接call?
调用失败了没返回值?直接扔异常?
exception 老早就是个自动unwind stack, 回收资源的东西。结果有事没事当return
code一样乱扔, 造出来的问题比解决的问题更多。
long
【在 g*****g 的大作中提到】
: Checked Exception至少帮助你去想想要不要处理一个Exception。举个例子，你在一个
: 循环里调用一个远程的服务，远程服务没有不出错的。有个Checked Exception你就会
: 逼你思考一下是要在循环里catch，在循环外catch，在方法上直接抛。三种处理只有一
: 种是对的。你要是没Checked Exception，可能根本不会注意到这是个远程调用，结果
: 很可能测试啥的都好，甚至产品上也一直都好，某天网络顿了一下，bug出来了。
: fix一个产品上的bug，成本至少是一个fix dev里bug的100倍。Java的这点繁琐，能帮
: 助你避免很多问题。特别是这年头强调time to market，测试充分很难保证。前端的应
: 用还好，出这种事情往往只影响到个别用户，重试一下可能也过了。后端可能一个long
: running job废了，你半夜被叫起来了。Java在后端这么dominant不是没有理由的。
|
g*****g
发帖数: 34805 | 9 出个网络问题，你能有啥返回值？当然是抛异常。我远程调用要返回个随机整数，网络
坏了，你打算用啥？包不包有区别吗？出了异常抛异常本来就是正常的做法，调用者能
处理处理，不能处
理往外抛。生生用error code才不合适。
【在 l*******b 的大作中提到】
: 远程调用不包装直接call?
: 调用失败了没返回值?直接扔异常?
: exception 老早就是个自动unwind stack, 回收资源的东西。结果有事没事当return
: code一样乱扔, 造出来的问题比解决的问题更多。
:
: long
|
c******o
发帖数: 1277 | 10 Future就是这个use case,对吧
返回值是啥？
abstract def value: Option[Try[T]]
你有一个Future, 硬问value,那么还没有就返回None
有了就返回值或者一个Exception
很好的capture问题的本质，而且可以用map/flatMap一直传下去，这是为啥我那么喜欢
Future/FP
省了不知道多少脑细胞。
【在 g*****g 的大作中提到】
: 出个网络问题，你能有啥返回值？当然是抛异常。我远程调用要返回个随机整数，网络
: 坏了，你打算用啥？包不包有区别吗？出了异常抛异常本来就是正常的做法，调用者能
: 处理处理，不能处
: 理往外抛。生生用error code才不合适。
|
|
|
l*******b
发帖数: 2586 | 11 高大上的随机整数, 只有服务器可以生成。举个好点的例子吧, 忽悠也花点功夫, 不然
就是吵架。没意思
【在 g*****g 的大作中提到】
: 出个网络问题，你能有啥返回值？当然是抛异常。我远程调用要返回个随机整数，网络
: 坏了，你打算用啥？包不包有区别吗？出了异常抛异常本来就是正常的做法，调用者能
: 处理处理，不能处
: 理往外抛。生生用error code才不合适。
|
z****e
发帖数: 54598 | 12 网络调用返回一个error code有啥用？
internal error，你告诉我这个等于没说
我当然希望要exception，哪怕只是printstack也远比给个error code强
404这种等于没说，什么原因？不知道
只知道出了个错，还是给异常吧，至少信息多，我看异常还能看出点问题来
error code看到就想杀人
【在 l*******b 的大作中提到】
: 远程调用不包装直接call?
: 调用失败了没返回值?直接扔异常?
: exception 老早就是个自动unwind stack, 回收资源的东西。结果有事没事当return
: code一样乱扔, 造出来的问题比解决的问题更多。
:
: long
|
g*****g
发帖数: 34805 | 13 错了，Future是Non-blocking的，我说的是blocking的，当然你可以call get让它
blocking。你当然也可以wrap Option在Exception上，但这本质上跟一个Checked
Exception逼你做决定也没啥区别，不过带个套罢了。
【在 c******o 的大作中提到】
: Future就是这个use case,对吧
: 返回值是啥？
: abstract def value: Option[Try[T]]
: 你有一个Future, 硬问value,那么还没有就返回None
: 有了就返回值或者一个Exception
: 很好的capture问题的本质，而且可以用map/flatMap一直传下去，这是为啥我那么喜欢
: Future/FP
: 省了不知道多少脑细胞。
|
g*****g
发帖数: 34805 | 14 看来你是真没见过的。我老给Casino公司写过应用，随机数必须硬件生成，否则audit
都通不过。你当然可以说这是special case，一个语言应该是business agnostic的。
【在 l*******b 的大作中提到】
: 高大上的随机整数, 只有服务器可以生成。举个好点的例子吧, 忽悠也花点功夫, 不然
: 就是吵架。没意思
|
z****e
发帖数: 54598 | 15 那这种思维方式还是exception式的思维方式
换汤不换药，还是用exception吧，至少会java的都能看得懂
你把exception放到future里面，定义了某一种情况时候可以get这个exception
那这个意味着你要么在注释中要写出来，要么就要在文档中标明
我估计你可能两个都没做，如果都没做的话
那别人要猜出你这里有exception，有难度
【在 c******o 的大作中提到】
: Future就是这个use case,对吧
: 返回值是啥？
: abstract def value: Option[Try[T]]
: 你有一个Future, 硬问value,那么还没有就返回None
: 有了就返回值或者一个Exception
: 很好的capture问题的本质，而且可以用map/flatMap一直传下去，这是为啥我那么喜欢
: Future/FP
: 省了不知道多少脑细胞。
|
c******o
发帖数: 1277 | 16 It enforce you think in someway (do it locally if possible, instead of throw
to higher level), instead of just throw the error around.
Even use it like a exception throwing, it make it easier by wraping it.
Yes， This is more about non blocking.
Blocking mistake is really bad in reactive programming, and we try to avoid.
reactive/resilience/responsive means always return meaningful information
back to user with a timely manner, even it some error internally.
【在 g*****g 的大作中提到】
: 错了，Future是Non-blocking的，我说的是blocking的，当然你可以call get让它
: blocking。你当然也可以wrap Option在Exception上，但这本质上跟一个Checked
: Exception逼你做决定也没啥区别，不过带个套罢了。
|
c******o
发帖数: 1277 | 17 尽量不要有Exception,如果有， 那看local能不能处理成有意义的value,如果不能，才
把Exception回传，然后这样会传也比Exception Throw 简单多了， 不用你自己对返回
值判断 （map/flatMap）帮你做了。
【在 z****e 的大作中提到】
: 那这种思维方式还是exception式的思维方式
: 换汤不换药，还是用exception吧，至少会java的都能看得懂
: 你把exception放到future里面，定义了某一种情况时候可以get这个exception
: 那这个意味着你要么在注释中要写出来，要么就要在文档中标明
: 我估计你可能两个都没做，如果都没做的话
: 那别人要猜出你这里有exception，有难度
|
l*******b
发帖数: 2586 | 18 大牛威武, 这么重要的数也舍不得写个 wrapper包装一下, 异常扔出来吓倒小朋友怎么
办。前两天那个火箭一样, 据说还是专门翻修过得。:D
audit
【在 g*****g 的大作中提到】
: 看来你是真没见过的。我老给Casino公司写过应用，随机数必须硬件生成，否则audit
: 都通不过。你当然可以说这是special case，一个语言应该是business agnostic的。
|
g*****g
发帖数: 34805 | 19 It makes no difference. Checked Exception forces you to do something, even
throw exception is a decision you make. The point is that you are forced to
do something instead of nothing like most dynamic languages are doing.
And blocking and non-blocking are used for different purposes. I don't get
the point of your using non-blocking to illustrate blocking situation.
throw
avoid.
【在 c******o 的大作中提到】
: It enforce you think in someway (do it locally if possible, instead of throw
: to higher level), instead of just throw the error around.
: Even use it like a exception throwing, it make it easier by wraping it.
: Yes， This is more about non blocking.
: Blocking mistake is really bad in reactive programming, and we try to avoid.
: reactive/resilience/responsive means always return meaningful information
: back to user with a timely manner, even it some error internally.
|
g*****g
发帖数: 34805 | 20 我包了，包完了还是得抛出个异常，区别不过只是把Exception换一下处理比较规整而
已。
你不抛异常你跟我说说那个数可以做Error code? 编程版就不用来跟我行为艺术了吧。
【在 l*******b 的大作中提到】
: 大牛威武, 这么重要的数也舍不得写个 wrapper包装一下, 异常扔出来吓倒小朋友怎么
: 办。前两天那个火箭一样, 据说还是专门翻修过得。:D
:
: audit
|
|
|
c******o
发帖数: 1277 | 21 I agree it make no difference in the end. Future can do Blocking with Await,
but in this kind of scenario, I prefer still do non blocking (when wait
for the remote response, do something else).
对楼主的问题， 我就是说其实他说的都能做，只是选择不这么做而已。
to
【在 g*****g 的大作中提到】
: It makes no difference. Checked Exception forces you to do something, even
: throw exception is a decision you make. The point is that you are forced to
: do something instead of nothing like most dynamic languages are doing.
: And blocking and non-blocking are used for different purposes. I don't get
: the point of your using non-blocking to illustrate blocking situation.
:
: throw
: avoid.
|
l*******b
发帖数: 2586 | 22 函数返回一个状态, 另传给个地址指针写 output. 哎呀忘了java不能这样搞。。。还
是Exception好, 一个函数终于可以返回两个值了, 一个数, 一个状态。提壶灌顶, 豁
然开朗, 大牛呀, 拜一拜
【在 g*****g 的大作中提到】
: 我包了，包完了还是得抛出个异常，区别不过只是把Exception换一下处理比较规整而
: 已。
: 你不抛异常你跟我说说那个数可以做Error code? 编程版就不用来跟我行为艺术了吧。
|
z****e
发帖数: 54598 | 23 还在迷恋语言中的这点小技巧
传什么地址啊，丢给一个static map，然后把key return
不就可以了？
顺便，exception的意思就是意外
如果你能想到的，在你意料之中的，都不叫意外
【在 l*******b 的大作中提到】
: 函数返回一个状态, 另传给个地址指针写 output. 哎呀忘了java不能这样搞。。。还
: 是Exception好, 一个函数终于可以返回两个值了, 一个数, 一个状态。提壶灌顶, 豁
: 然开朗, 大牛呀, 拜一拜
|
z****e
发帖数: 54598 | 24 但是我能想到的话，我就不丢exception了
java代码要写成这样一点都不难
但是因为很多时候要用到第三方类库
第三方类库会抛各种异常，这个往往在意料之外
我如果能穷尽所有的情况，我就不用exception了
就是因为我觉得不可能把所有情况全部考虑到
才有必要使用exception呀
【在 c******o 的大作中提到】
: 尽量不要有Exception,如果有， 那看local能不能处理成有意义的value,如果不能，才
: 把Exception回传，然后这样会传也比Exception Throw 简单多了， 不用你自己对返回
: 值判断 （map/flatMap）帮你做了。
|
l*******b
发帖数: 2586 | 25 呵呵, 玩笑了, 意料之外都能handle, 那不是成半个神仙
【在 z****e 的大作中提到】
: 还在迷恋语言中的这点小技巧
: 传什么地址啊，丢给一个static map，然后把key return
: 不就可以了？
: 顺便，exception的意思就是意外
: 如果你能想到的，在你意料之中的，都不叫意外
|
z****e
发帖数: 54598 | 26 lol
你总算明白自己是半仙了
连exception这个general的东西都不用
自己挨个去定义error code，这个半仙真不是一般的牛逼
【在 l*******b 的大作中提到】
: 呵呵, 玩笑了, 意料之外都能handle, 那不是成半个神仙
|
c******o
发帖数: 1277 | 27 en, 所以两个都能用。
但是推荐不用 throw exception.
像goodbug说的最后都一样，那为什么能在这儿处理不处理呢？
不能处理的话，wrap in Try往外传更好。
【在 z****e 的大作中提到】
: 但是我能想到的话，我就不丢exception了
: java代码要写成这样一点都不难
: 但是因为很多时候要用到第三方类库
: 第三方类库会抛各种异常，这个往往在意料之外
: 我如果能穷尽所有的情况，我就不用exception了
: 就是因为我觉得不可能把所有情况全部考虑到
: 才有必要使用exception呀
|
g*****g
发帖数: 34805 | 28 你这是C没有办法的办法，为了一个Exception，多传一个参数进来，还有side effect
。要document，异常的时候，这个output会返回blah blah。相比signature上写得明明
白白throw ConnectionException逼着你catch哪个好不是显然的？
更重要的，你往往会忘了还要干这个。直到产品环境里出来，傻逼了。从这个角度讲，
不管什么语言，在类似的情况下都必须做相同的处理。只不过Java提供了一种更清晰的
实现，并且依赖编译器强迫你开发的时候处理。
【在 l*******b 的大作中提到】
: 函数返回一个状态, 另传给个地址指针写 output. 哎呀忘了java不能这样搞。。。还
: 是Exception好, 一个函数终于可以返回两个值了, 一个数, 一个状态。提壶灌顶, 豁
: 然开朗, 大牛呀, 拜一拜
|
H****S
发帖数: 1359 | 29 Try只能包住nonFatal exception，如果运气不好碰到一个fatal exception，恰好你的
business logic又需要对此情况进行特殊处理，那就挂了。这个不是不可能存在：比如
Lucene在做document indexing的时候，如果碰到OOM，它的javadoc是要求立刻关闭对
应的index writer，不巧OOM就是Try保不住的exception之一。
【在 c******o 的大作中提到】
: en, 所以两个都能用。
: 但是推荐不用 throw exception.
: 像goodbug说的最后都一样，那为什么能在这儿处理不处理呢？
: 不能处理的话，wrap in Try往外传更好。
|
c******o
发帖数: 1277 | 30 That is exactly why Try do not work on fatal exception
https://github.com/alexandru/scala-best-practices/blob/master/sections/2-
language-rules.md#28-must-not-catch-throwable-when-catching-exceptions
【在 H****S 的大作中提到】
: Try只能包住nonFatal exception，如果运气不好碰到一个fatal exception，恰好你的
: business logic又需要对此情况进行特殊处理，那就挂了。这个不是不可能存在：比如
: Lucene在做document indexing的时候，如果碰到OOM，它的javadoc是要求立刻关闭对
: 应的index writer，不巧OOM就是Try保不住的exception之一。
|
|
|
g*****g
发帖数: 34805 | 31 当然不是，你可以catch Throwable，但你得确保你知道你在干什么。所有server 最外
圈都是要catch Throwable的，运行时不能因为一个Error就退出JVM。
【在 H****S 的大作中提到】
: Try只能包住nonFatal exception，如果运气不好碰到一个fatal exception，恰好你的
: business logic又需要对此情况进行特殊处理，那就挂了。这个不是不可能存在：比如
: Lucene在做document indexing的时候，如果碰到OOM，它的javadoc是要求立刻关闭对
: 应的index writer，不巧OOM就是Try保不住的exception之一。
|
q*c
发帖数: 9453 | 32 为什么？就因为我们是人这种低等生物，大部分时候必须要强迫才能好好做事情
exeption 没啥神奇的,就是在每一层上强迫你考虑一下 error case.
就这一点点强迫，质量就是完全不同。如果我们都是计算机生命，不会忘记，不会犯错
，那根本不需要 exception 这种笨重的东西。
【在 c******o 的大作中提到】
: en, 所以两个都能用。
: 但是推荐不用 throw exception.
: 像goodbug说的最后都一样，那为什么能在这儿处理不处理呢？
: 不能处理的话，wrap in Try往外传更好。
|
H****S
发帖数: 1359 | 33 I don't know if we are on the same page. Future cannot capture fatal
exceptions, which means if fatal exception does happen, you don't have a
callback to rescue your business logic right the fuck now.
[在 coltzhao (coltzhao) 的大作中提到：]
：That is exactly why Try do not work on fatal exception
：
：........... |
H****S
发帖数: 1359 | 34 我的意思是关闭Lucene index writer，不是说要关掉JVM。
[在 goodbug (好虫) 的大作中提到：]
：当然不是，你可以catch Throwable，但你得确保你知道你在干什么。所有server 最
外圈都是要catch Throwable的，运行时不能因为一个Error就退出JVM。
：
：........... |
p*****2
发帖数: 21240 | 35
fatal exception crash也正常吧？
【在 H****S 的大作中提到】
: I don't know if we are on the same page. Future cannot capture fatal
: exceptions, which means if fatal exception does happen, you don't have a
: callback to rescue your business logic right the fuck now.
: [在 coltzhao (coltzhao) 的大作中提到：]
: ：That is exactly why Try do not work on fatal exception
: ：
: ：...........
|
z****e
发帖数: 54598 | 36 如果是发生在半夜，有人要被oncalled了
【在 p*****2 的大作中提到】
:
: fatal exception crash也正常吧？
|
p*****2
发帖数: 21240 | 37
现在互联网公司oncall都是常态了。不过AKKA不就是let it crash吗？
【在 z****e 的大作中提到】
: 如果是发生在半夜，有人要被oncalled了
|
g*****g
发帖数: 34805 | 38 akka crash的是一个 actor, 或者说一个 job而已。
【在 p*****2 的大作中提到】
:
: 现在互联网公司oncall都是常态了。不过AKKA不就是let it crash吗？
|
p*****2
发帖数: 21240 | 39
如果把任务分解到actor中，是不是就可以了？
【在 g*****g 的大作中提到】
: akka crash的是一个 actor, 或者说一个 job而已。
|
