Aspects of error handling - Revision history

Logmanoriginal: Add to Error Handling category

2021-01-17T14:53:42Z

Add to Error Handling category

← Older revision		Revision as of 14:53, 17 January 2021
Line 73:		Line 73:

	[[Category:LabVIEW fundamentals]]		[[Category:LabVIEW fundamentals]]
			[[Category:Error Handling]]

Logmanoriginal: Remove duplicate reference

2021-01-17T14:53:09Z

Remove duplicate reference

← Older revision		Revision as of 14:53, 17 January 2021
Line 1:		Line 1:
	{{TOCnestright}}		{{TOCnestright}}
	'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.		'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
	LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref~~>Nattinger, Darren. [http://bit.ly/~~dnatterrors "~~What to Expect When You're Expecting an Error"] (NIWeek 2018)<~~/~~ref~~>		LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref name="dnatterrors"/>

	{\| class="wikitable" style="text-align: left;"		{\| class="wikitable" style="text-align: left;"
Line 42:		Line 42:
	The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.		The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

	Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref~~>Nattinger, Darren. [http://bit.ly/~~dnatterrors "~~What to Expect When You're Expecting an Error"] (NIWeek 2018)<~~/~~ref~~>		Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref name="dnatterrors"/>
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.<br><br>		\| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.<br><br>
Line 68:		Line 68:

	== References ==		== References ==
			<references>
			<ref name="dnatterrors">Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
			</references>

	[[Category:LabVIEW fundamentals]]		[[Category:LabVIEW fundamentals]]

Logmanoriginal: Logmanoriginal moved page Error handling to Aspects of error handling: This page explains the aspects of error handling, it is not a portal page.

2021-01-17T14:50:06Z

Logmanoriginal moved page Error handling to Aspects of error handling: This page explains the aspects of error handling, it is not a portal page.

← Older revision	Revision as of 14:50, 17 January 2021
(No difference)

Smercer: improve table spacing

2019-07-12T16:14:30Z

improve table spacing

Smercer: fix table alignment

2019-07-12T16:11:34Z

fix table alignment

← Older revision		Revision as of 16:11, 12 July 2019
Line 3:		Line 3:
	LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>		LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

	{\| class="wikitable"		{\| class="wikitable" style="text-align: left;"
	\|-		\|- style="vertical-align:top;"
	! Aspect !! Details		! Aspect !! Details
	\|-		\|- style="vertical-align:top;"
	\| '''Error Generation''' is the creation of an [[Error cluster\|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).		\| '''Error Generation''' is the creation of an [[Error cluster\|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).
	\|\| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:		\|\| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
	# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''		# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
	# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.		# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
	\|-		\|- style="vertical-align:top;"
	\| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.		\| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.
	\|\| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.		\|\| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.
Line 28:		Line 28:
	* '''Unused Code''' - Detects unwired output tunnels of structures		* '''Unused Code''' - Detects unwired output tunnels of structures
	* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)		* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
	\|-		\|- style="vertical-align:top;"
	\| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:		\| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:
	* Ignoring certain errors		* Ignoring certain errors
Line 40:		Line 40:

	Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>		Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
	\|-		\|- style="vertical-align:top;"
	\| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.		\| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.
	\|\| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.		\|\| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.
Line 47:		Line 47:

	You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.		You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
	\|-		\|- style="vertical-align:top;"
	\| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.		\| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.
	\|\| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.		\|\| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

Smercer: specify who these people are

2019-07-12T15:55:30Z

specify who these people are

← Older revision		Revision as of 15:55, 12 July 2019
Line 1:		Line 1:
	{{TOCnestright}}		{{TOCnestright}}
	'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.		'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
	Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>		LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

	{\| class="wikitable"		{\| class="wikitable"

Smercer: Fix statement of intro to be less factual and instead attribute to expert opinion

2019-07-12T15:54:14Z

Fix statement of intro to be less factual and instead attribute to expert opinion

← Older revision		Revision as of 15:54, 12 July 2019
Line 1:		Line 1:
	{{TOCnestright}}		{{TOCnestright}}
	'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.		'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
	~~The~~ five (5) aspects of error handling below were introduced by Stephen Loftus-Mercer in several informal settings; Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>		Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

	{\| class="wikitable"		{\| class="wikitable"

Smercer: correct attribution

2019-07-12T15:45:27Z

correct attribution

← Older revision		Revision as of 15:45, 12 July 2019
Line 36:		Line 36:
	\|\|		\|\|
	[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png\|600px\|thumb]]		[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png\|600px\|thumb]]
	See ~~Darren Nattinger~~'s poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].		See Stephen Loftus-Mercer's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].
	The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.		The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

Smercer: Significant rewrite... changed formatting to make it easier to review the topics. In future, may consider breaking each into separate page.

2019-07-12T15:44:36Z

Significant rewrite... changed formatting to make it easier to review the topics. In future, may consider breaking each into separate page.

← Older revision		Revision as of 15:44, 12 July 2019
Line 1:		Line 1:
	{{TOCnestright}}		{{TOCnestright}}
	'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and ~~SubVIs~~ that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.		'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
	The five (5) aspects of error handling below were introduced by Darren Nattinger.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>		The five (5) aspects of error handling below were introduced by Stephen Loftus-Mercer in several informal settings; Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

	=~~= Error Generation ==~~		{\| class="wikitable"
	'''Error Generation''' is the creation of an [[Error cluster\|error cluster]] value at the point that something goes wrong in your LabVIEW code. An error ~~should only~~ be ~~generated~~ in two ~~ways~~:		\|-
	# ~~Output from a Built-in Node~~		! Aspect !! Details
	~~# G code that creates~~ an error value (i.e. an [[Error Ring]], or ~~using~~ ''Error Cluster from Error Code.vi'')		\|-
			\| '''Error Generation''' is the creation of an [[Error cluster\|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).
			\|\| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
			# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
			# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
			\|-
			\| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.
			\|\| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

	Alternatively, an [[Error cluster\|error cluster]] can be generated by bundling the Status boolean, Code numeric, and Source string together. However, by doing it this way, it will not automatically include the call chain or, for default error codes, the standard error message text for the code. Therefore, it is not recommended unless it is done in [[Real Time]] or [[FPGA]].		'''The number one rule of error propagation is ''Don't Break the Error Chain!''''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging\|debugging]] difficult.

	Output from a built-in node will result in a [[Default Error Code]]. Output from an [[Error Ring]] or the ''Error Cluster from Error Code.vi'' can result in a Default Error Code or a [[Custom Error Code]].

	~~== Error Propagation ==~~
	'''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a SubVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

	'''The number one rule of error propagation is Don't Break the Error Chain!''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging\|debugging]] difficult.

	An error chain can be broken in three ways:		An error chain can be broken in three ways:
Line 28:		Line 28:
	* '''Unused Code''' - Detects unwired output tunnels of structures		* '''Unused Code''' - Detects unwired output tunnels of structures
	* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)		* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
			\|-
	Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used.		\| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:

	~~== Error Response ==~~
	~~[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png\|600px~~\|~~thumb]]~~
	'''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. ~~The~~ ways ~~errors could be responded~~ to ~~include~~:
	* Ignoring certain errors		* Ignoring certain errors
	* Retrying the operation		* Retrying the operation
	* Translating or Modifying an error		* Translating or Modifying an error
	* Failing the operation and closing the program		* Failing the operation and closing the program
			\|\|
			[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png\|600px\|thumb]]
	See Darren Nattinger's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].		See Darren Nattinger's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].

	The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.		The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

	== Error ~~Display ==~~		Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
	'''Error Display''' is the act of displaying error information to the end user and/or code developer. ~~This~~ is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.		\|-
			\| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.
			\|\| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

	The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.		The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

	You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.		You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
			\|-
			\| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.
			\|\| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

			For more insight on why it is important to log "no error", please contemplate [http://thecodelesscode.com/case/48 the 48th koan of Codeless Code]: ''"The Protocols tell us of no fewer than Four Silences: the Silence Before Words, the Silence Between Words, the Silence of the Broken Pipe, and the Silence of Fallen Parcels. To the initiate they are as different as the characters for “end” 末 and “not yet” 未, although the outsider cannot tell one from the other."''
			\|}

	~~== Error Logging ==~~
	~~'''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis.~~

	== External Links ==		== External Links ==
Line 57:		Line 60:
	*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].		*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].
	*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]		*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]
			*[http://thecodelesscode.com/case/48 The Codeless Code, Koan 48]


	== References ==		== References ==

	[[Category:LabVIEW fundamentals]]		[[Category:LabVIEW fundamentals]]

MichaelAivaliotis at 09:23, 27 June 2019

2019-06-27T09:23:27Z

← Older revision		Revision as of 09:23, 27 June 2019
Line 32:		Line 32:

	== Error Response ==		== Error Response ==
			[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png\|600px\|thumb]]
	'''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. The ways errors could be responded to include:		'''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. The ways errors could be responded to include:
	* Ignoring certain errors		* Ignoring certain errors

← Older revision		Revision as of 16:14, 12 July 2019
Line 7:		Line 7:
	! Aspect !! Details		! Aspect !! Details
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| '''Error Generation''' is the creation of an [[Error cluster\|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).		\| '''Error Generation''' is the creation of an [[Error cluster\|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).<br><br>

	\|\| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:		\|\| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
	# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''		# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
	# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.		# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.		\| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.<br><br>

	\|\| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.		\|\| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

Line 34:		Line 36:
	* Translating or Modifying an error		* Translating or Modifying an error
	* Failing the operation and closing the program		* Failing the operation and closing the program
			<br><br>
	\|\|		\|\|
	[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png\|600px\|thumb]]		[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png\|600px\|thumb]]
Line 41:		Line 44:
	Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>		Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.		\| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.<br><br>
	\|\| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.		\|\| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

Line 49:		Line 52:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.		\| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.

	\|\| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.		\|\| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.