Namespaces
Variants
Views
Actions

Talk:cpp/error/error condition

From cppreference.com

It would be really great to explain that error_condition is orthogonal to error_code. And error_condition could be used to categories error_code in domain specific ways. Took me unnecessary long time to realise this. Lazan (talk) 05:04, 12 June 2021 (PDT) 

I don't think they are orthogonal, and error_codes are categorised in the same way as error_conditions from what I can tell. Off-topic: I don't know why, but the error code stuff has always come across to me as confusing and overengineered, and I've never seen anyone use it voluntarily IRL. --Ybab321 (talk) 05:17, 12 June 2021 (PDT)
Well, I do consider them orthogonal. Before I realised this I didn't understand the point of the whole `error_code`. I don't (any more) consider error code stuff _overengineered_, It's quite beautiful, once I understod the relation between error_code and error_condition (or the lack thereof). In my problem domain I use `error_code` for the actual detected error (propagated in some places via `system_error`), I have several _context dependent categories_ (error_condition) that I use to compare and dispatch on the actual action the system should take. A given value for a given error_condition compares equal to several `error_code`'s from possible different error_categories. Hence, orthogonal relation between the actual types and values (that is, there's no given or forced relation, the user/designer choses the relations, and the meaning of it).I find the resulting code very easy to reason about. But this information/insight did not come easy, thats why I think cppreference should try to explain this in a comprehensible way, since it's the go to reference for c++. Lazan (talk) 07:42, 13 June 2021 (PDT)
It sounds to me like you're implying that only std::error_condition is category dependent, which isn't the case, both types of error have the same categories. The only difference is that std::error_code is platform dependent and std::error_condition isn't, making the former of questionable value (I'm guessing it's down to implementations to guarantee that std::error_codes match up with OS based error codes). I don't really understand what you mean by "orthogonal" here either, as far as I can tell, there's a direct translation between the two types of error, and they both use the same std::error_categorys, they're so close to each other that they're essentially parallel. --Ybab321 (talk) 08:48, 13 June 2021 (PDT)
there was this intro blog when these things were new, by one of the authors: http://blog.think-async.com/2010/04/system-error-support-in-c0x-part-2.html (in a nutshell, error_code was not even going to be exposed until someone in the committee insisted that it's useful, and generally you don't want to use it except for comparison with zero) --Cubbi (talk) 20:32, 13 June 2021 (PDT)
FYI This is the only good example I've ever found: https://akrzemi1.wordpress.com/2017/07/12/your-own-error-code/
IMHO people "hear" or "see" "errc" as an abbreviation for "error code" as people talk more of error codes than error conditions and very few read the documentation to see that they are wrong or what the distinction is.

194.74.130.171 01:23, 14 June 2021 (PDT)

well, std::future_errc and std::io_errc are error codes, while std::errc is error condition. That's a bit of an unfortunate abbreviation. --Cubbi (talk) 07:54, 14 June 2021 (PDT)

According to the following blog article (https://akrzemi1.wordpress.com/2017/08/12/your-own-error-condition/, from a source very involved in the community), I think cppreference describes error_condition all wrong and it's influencing answers on Stack Overflow. I agree with the comment from Lazan (talk). error_code is for error coming from the library or users's subsystem and error_condition is to group error_code into errors to be presented to the user for example. This is what error_category::equivalent is for. For example, error_codes "file does not exist" and "json text is invalid" would both be equivalent to error_condition "cannot read config". If it becomes clear a change should be done, how does that happen on cppreference? --Philtherobot (talk) 07:38, 25 April 2022 (PDT)

Sounds like you're describing a specific project convention, as far as I can tell, error_conditions aren't required to be more general or vague than corresponding error_codes. We could maybe talk about conventions, but it's not clear to me why that convention would be useful, I would have thought you'd would want a library to give you a portable error_condition rather than a non-portable error_code unless it's a platform specific library --Ybab321 (talk) 09:26, 25 April 2022 (PDT)
If I understand the reported omission correctly, we could mention in cpp/error/error_category that categories do not have to be 1:1 and are allowed to map multiple codes to the same condition. --Cubbi (talk) 10:53, 25 April 2022 (PDT)