I have a question, who throws exceptions to indicate logic errors?
I do. In a production server environment, I want to catch logic errors with an exception trace (nested exceptions) and the emit that nested exception info to a FATAL log record so it can be investigated. Of course in a debug build, this will assert first, but that's the last thing I want in production. On 23 January 2018 at 21:42, Emil Dotchevski via Boost < boost@lists.boost.org> wrote:
On Tue, Jan 23, 2018 at 6:44 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
I'm liking what I saw so far. Just a small comment on the documentation. I'm curious what the following sentence does even mean? Is it supposed to confuse the user or something? It's a sign of bad taste really.
Outcome’s default is to not provide value-or-error objects. It
On 23/01/2018 13:52, Vinícius dos Santos Oliveira via Boost wrote: provides
success-or-failure objects.
What does that even mean? value-or-error... well, if it is non-error, I assume it is success. Both sentences mean just the same. As do their API (encapsulate either A or B). The rest of the paragraph is okay. If you just remove this comment, confusion will go away. No other changes need to be done in this paragraph. Just remove this misleading means-nothing comment.
Literally, straight after what you quoted it says:
"Outcome’s default is to not provide value-or-error objects. It provides success-or-failure objects. We define the difference as being “having programmable actions in response to no-value observation other than throwing a hard coded logic error type exception”."
Can you explain why this is confusing to you?
I have a question, who throws exceptions to indicate logic errors?
Emil
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost