4 ms·

> This is hardly possible. The whole idea of exceptions is that each function only deals with a subset. Why? It's totally possible to infer the most general ty

> This is hardly possible. The whole idea of exceptions is that each function only deals with a subset. Why? It's totally possible to infer the most general type for all the functions in the program, hence to infer the type of the needed handler. Any language with subtyping and powerful type inference can do this, here is the toy ocaml example with typed algebraic effects (you can think of them as of exceptions): val read_file : path -[ Not_found ]-> string val process_content : string -[ OOM | Intern_err of int ]-> float let computation path = let content = read_file path in let result = process_content content in if result < 0 then raise Bad_result else result the type of computation would be inferred as val computation : path -[ Not_found | OOM | Intern_err of int | Bad_result ]-> float The handler should catch the corresponding exceptions. This could also be used with the result monad as well [1]. Even if you want to keep some exceptions unhandled, you can easily choose which ones, and track them carefully. [1] https://keleshev.com/composable-error-handling-in-ocaml https://keleshev.com/composable-error-handling-in-ocaml

Mikhail_Edoshin 7y ago
It's possible to compute which exceptions can be raised, but it's impractical to handle each exception in each function (this is how I understood your comment, I guess this is not what you meant). E.g. nearly any call can technically raise an OutOfMemory error or an IntegerOverflow error, but most functions are not competent enough to handle that, all they can do is to clean up and raise this up the call stack. But it is indeed possible to have a single top-level handler (or a carefully constructed hierarchy of handlers) that explicitly handle all exceptions that may arise. (And to ignore an exception is also a form of handling.) The handler already exists, but it's pretty simple: for any exception it prints the error and terminates the program. It's up to developer to override this to make the program more robust.

Mikhail_Edoshin 7y ago

It's possible to compute which exceptions can be raised, but it's impractical to handle each exception in each function (this is how I understood your comment, I guess this is not what you meant). E.g. nearly any call can technically raise an OutOfMemory error or an IntegerOverflow error, but most functions are not competent enough to handle that, all they can do is to clean up and raise this up the call stack. But it is indeed possible to have a single top-level handler (or a carefully constructed hierarchy of handlers) that explicitly handle all exceptions that may arise. (And to ignore an exception is also a form of handling.) The handler already exists, but it's pretty simple: for any exception it prints the error and terminates the program. It's up to developer to override this to make the program more robust.