Why again is using bools to measure whether an operation is successful or not a bad thing? You'd be going against decades of well founded programming principles if you make such a claim. Errors are for errors. An unsuccessful operation may not necessarily mean the issue is an error. Here's a rule of thumb. If you doubt it's an error it's probably not an error. Errors are also costly because strings are created. Strings are expensive compared to a simple boolean. Use errors with care and with purpose.
The reason I recommend using errors (the error wire) to signal that an operation could not be performed is because that is the purpose of the error data structure (error cluster). There is no reason to use another mechanism (outputting a Boolean, an I32, or another data type) when a standard mechanism (the error cluster and error wire) is provided by the language. If the operation could not be performed, then there must be a reason it could not be performed. You can explain that reason in the error message (the “source” field of the error cluster). I agree that errors are more costly to generate compared to outputting a Boolean. When we are taking about creating a single error vs outputting a single Boolean the difference is probably measured in microseconds. This can make a meaningful difference only in situations where the error is created (and potentially cleared) inside a fast-iterating loop (e.g. 1,000 times per second or more). If this pattern is identified as a “hot-spot” or a bottle-neck in an application, then it is ok to refactor and output a Boolean, thus removing the generation of the string and the clearing of the error. An informative comment should be added in this situation to explain why the standard error mechanism is not used. “You'd be going against decades of well founded programming principles if you make such a claim.” - Can you reference a book, article, or resource that advises the use of Booleans to signal that an operation could not be performed? If you use other programming languages such as C#, Java, or Python, do you output a Boolean or do you throw an exception? My preference and recommendation would be to throw an exception if the method could not perform what it was asked to do. This is equivalent to generating an error in LabVIEW. “Errors are for errors.” - What do you mean exactly? In the beginning of the presentation I define an error as a situation where an operation could not be performed. How do you define errors?
![⭐ฮิตในTikTok!! ( หมูเด้ง MooDeng ) Ver. แดนซ์โจ๊ะๆ ReMix BY [ ดีเจกิต รีมิกซ์ ]](http://i.ytimg.com/vi/3krsyfWUeHU/mqdefault.jpg)
![CAMPปลิ้น | EP.83[2/2] ประสบการณ์ขนหัวลุกจากตำนานวงการผี!](http://i.ytimg.com/vi/T_kFecQw7Ds/mqdefault.jpg)
Why again is using bools to measure whether an operation is successful or not a bad thing?
You'd be going against decades of well founded programming principles if you make such a claim.
Errors are for errors. An unsuccessful operation may not necessarily mean the issue is an error.
Here's a rule of thumb. If you doubt it's an error it's probably not an error.
Errors are also costly because strings are created. Strings are expensive compared to a simple boolean. Use errors with care and with purpose.
The reason I recommend using errors (the error wire) to signal that an operation could not be performed is because that is the purpose of the error data structure (error cluster). There is no reason to use another mechanism (outputting a Boolean, an I32, or another data type) when a standard mechanism (the error cluster and error wire) is provided by the language.
If the operation could not be performed, then there must be a reason it could not be performed. You can explain that reason in the error message (the “source” field of the error cluster).
I agree that errors are more costly to generate compared to outputting a Boolean. When we are taking about creating a single error vs outputting a single Boolean the difference is probably measured in microseconds. This can make a meaningful difference only in situations where the error is created (and potentially cleared) inside a fast-iterating loop (e.g. 1,000 times per second or more). If this pattern is identified as a “hot-spot” or a bottle-neck in an application, then it is ok to refactor and output a Boolean, thus removing the generation of the string and the clearing of the error. An informative comment should be added in this situation to explain why the standard error mechanism is not used.
“You'd be going against decades of well founded programming principles if you make such a claim.” - Can you reference a book, article, or resource that advises the use of Booleans to signal that an operation could not be performed?
If you use other programming languages such as C#, Java, or Python, do you output a Boolean or do you throw an exception? My preference and recommendation would be to throw an exception if the method could not perform what it was asked to do. This is equivalent to generating an error in LabVIEW.
“Errors are for errors.” - What do you mean exactly? In the beginning of the presentation I define an error as a situation where an operation could not be performed. How do you define errors?