FINEARCHS
FINEARCHS
>普通の1 + "a"みたいな式でもErrorを返すということ？ とりあえずはモナドのように失敗可能性のある処理にだけErrorを返させようと思っています。
`1+'a'`のような事前回避が容易なエラーはその場で強制終了にするのは賛成ですが、復帰可能性の概念は曖昧で基準にしづらい気がします。何故`Json:parse`が復帰可能で`1+'a'`やゼロ除算は復帰不可能なのかよく分かりません。 `err+1`のような事態で単純な型エラーにせずerrに内包されたエラーを出すのは、出来るだけ今まで同様にエラーを出したいという意図があります。（更新履歴を頻繁に確認する習慣がない人は、急に訳の分からない型エラーが出たら途方に暮れてしまうと思います） とはいえ、これだと先で言われていたような「エラーの発生が遅延されてかえって分かりにくくなる」問題が発生してしまいます。そこで、例えば ``` number expected but got error. Error Message: "Unexpected end of JSON input" ``` のような複合のエラーメッセージを出すのはどうでしょうか？
``` try { someFunc() } catch(e) { processError(e) } ``` でやりたいことは基本的に ``` let result=someFunc() if (Core:type(result) == 'error') processError(result) ``` で出来るはずなのでその問題はないと思います。
エラーを例外ではなく返り値の型で表すことの利点の一つは（静的型チェックを行うシステムであれば）エラーの種類まで含めて型システムが働くことであり、try-catch文が混ざるとこの利点が消えてしまいます。 また、もう一つの利点は（静的型チェックがあれば）プログラマにエラーの処理を強制出来ることなので >ifで分岐、returnしてエラーを呼び出し元に伝える必要がある これがむしろ利点になります。 （現状は静的型チェックがないのでただ面倒になっているだけですが…）
せめて ``` result? //if Core:type(result) == 'error' return result else result catch(result) {...} // if Core:type(result) == 'error' {...} ``` みたいなシンタックスシュガーは用意すべきかも…？
throw-catchの話ではなく、基本的にはその場で実行を停止するようにしたいという話ですか？
エラーを型で表す方式は厳格な型システムを前提としているので、「とりあえず動けば良いというようなスクリプトの使い方」とは思想が真っ向から対立するんですよね…
話を遡りますが、 @saki-lere さんの言っていた「復帰不可能な」エラーとは、「事前回避可能な」エラーをそう呼んでいるという認識で正しいでしょうか？ そうであれば、そのようなエラーを即時停止の扱いにする理由が分かってきた気がします。（型システムに組み込むと型チェックが複雑になりすぎる）
@marihachi という訳で、エラーを「即時停止するエラー」と「処理すべきエラー」に分けようと思うのですが、どうでしょうか？
あんまりキーワードを増やすのも良くないですしね… `arr.insert(idx, value)`や`arr.delete(idx)`が妥当ですかね `arr.insertRange(from, to, array)`や`arr.deleteRange(from, to)`もあると便利かも？