Typed throws (why not) #1257
Replies: 1 comment 1 reply
-
This is a very nice summary of concerns regarding statically specifying error types. I was thinking of responding to the ongoing design of #1261, but I think feedback is more appropriate here. I'm coming from a real-time embedded domain, so my needs may differ from others.
To me, throwing could be optimal for expressing local errors two since I can separate a normal path and an error path cleanly in code. I think language "throw" feature is superior to a
I may be reading into this, but "code does not care about the types of thrown errors" sounds like type-erasure. I want exceptions without dynamic allocation, but I don't know how to return exceptions on the stack unless the compiler knows the type. I won't throw strings, vectors, or other types with unbounded size, but maybe I'm going to throw an enum or struct which could be logged.
This is kind of a problem in C++ where we have throwing, non-throwing, and functions that signal errors another way. I would prefer if there was "one true way" to signal an error that was useable by all and all library authors could be reasonably expected to adhere to. I recently watched Peter Muldoon's C++Now talk in which he highlights how difficult it is for a library author to anticipate how their code will be applied by a user. To me, offering a I definitely appreciate the burden of adding an error type as a generic parameter or spelling it explicitly. If there was a way to avoid this without loosing the ability to use the stack for exceptions I would support it. I'm not sure how that can be achieved, but that's due to my insufficient knowledge. |
Beta Was this translation helpful? Give feedback.
-
This is a place to point people to when statically specifying what errors can be thrown from a function comes up for discussion.
I oppose such a feature for the following reasons. That isn't to say we won't entertain counter-arguments, but they will have to outweigh these reasons and the added language complexity will need to seem justified.
Result
, etc. for the lowest-level operations that might need to be retried, or where other error-specific recovery actions are likely)Beta Was this translation helpful? Give feedback.
All reactions