Hey, can I revive this discussion a bit? I skimmed over it and I personally think it got side-tracked into a Either/Result-oriented design discussion. Let’s bring it back to specifically checked exceptions and maybe try to simplify a bit.
My suggestion is this: have an analysis tool which checks Scala code for use of the throw keyword without a corresponding try ... catch which catches that exception in the same method. If it finds such usage, log a warning. If the method that uses throw is annotated with a @throws[...] annotation for the same exception type that’s being thrown, then don’t log a warning. This way exception warnings are propagated (or not) throughout the call graph in the same way as exceptions are.
To be clear, this is not my original idea, it is a pretty much straight up copy of Reanalyze from the OCaml ecosystem: reanalyze/EXCEPTION.md at master · rescript-association/reanalyze · GitHub . That document is short and very much worth reading.
The advantages of using the existing @throws annotation:
- No new keywords needed
- Codebases which use the annotation already will automatically work with this checker
The checker itself can be implemented in a few different places: as a Scala compiler warning, or perhaps an sbt plugin, or maybe even just a completely separate tool. In fact, reanalyze could maybe even be ported over to analyze Scala, since someone has written a Scala parser for OCaml: pfff/Parser_scala_recursive_descent.ml at develop · returntocorp/pfff · GitHub