Error handling

[stratosn]

reporter issue reference	document (UM/RM/EBNF)	page	line
PL-CSO-20	UM	104	3611
BDI-15	UM	105	All

---

Issue Description

(PL-CSO-20) An error is identified by the string “VTL-“ followed by a four digit code, where only two digits identifies specific code. This might be not enough for some categories.

(BDI-15) Error handling: the error information shoul be unified, because it allows redundant and non-coherent possibilities, in particular for the ERRORMESSAGE. For some operators ERRORCODE, ERRORLEVEL is mentioned, for other ERRORMESSAGE, ERRORLEVEL.

Proposed Solution

(PL-CSO-20) It should be considered to extend number of digits or extend it to four digits or letters.

(BDI-15) Identify just one output structure for error information. Remove ERRORMESSAGE, the specific properties of the error (message, locale, actions to adopt,…) should be part of an error registry. Otherwise the ErrorMessage need to be multilingual and have many other properties which are not a matters of a language for calculations like VTL.

Discussion in Paris

77-78: error handling

• maybe error handling can be left outside of the language (this also was the decision with VTL 1.0);
• the first problem is whether allowing or not allowing the error message.
• in some situations we are going to have codes that are coded and codes that are strings.
• should we include the messages? The strings? In VTL we would just build a connection with another system that actually implements the error handling. We don't want that the VTL, which is just for calculation, solves the problem of calculation and errors. The error code is the connection with an external system that provides for it.
• Maurizio would like a code that can be a string.

DISCUSSION

• ERROR MESSAGES in one Dataset in JOIN with the outcome of the CHECK. We are going to produce a CODE out of the check, to be then joined with a Dataset of error messages. The CODE is described externally.
• ERRORLEVEL Integer or String? Integers have the PRO to have an order that is the induced into the description. Different institutions can use different words to represent different levels. Integers can help harmonize and follow an order. Codes support localization. Messages have the PRO of being explicit from the user point of view.

--> For both the cases we are going to provide examples of the join between the outcome of the check and the two external tables, one for the ERROR MESSAGES and one of ERRORLEVEL.

--> the problem is not closed.

@dragan-ivanovic's PROPOSAL:

error codes : pure codes error levels : pure codes function to decode these codes (containing the join)

However, @capacma would like a textual description in the CHECK to help the user understand what the error is. Elaborate on the format of the code (for Poland 4 digits where insufficient).

The problem is still open. The ERRORLEVEL and ERRORCODE can be even be a code item from a code list (in order to have a pop-up in an application).

CONCLUSION

first step: @bellomarini and @dragan-ivanovic to produce an example

[bellomarini]

Agree with Dragan's proposal (codes + function). In particola ERRORLEVEL and ERRORCODE should be code items from code lists, containing the description. The code items could be either numeric or strings, to make them self-explanatory.

[capacma]

VTL is designed to exchange validation rules between organisations therefore VTL should be flexible enough to be compatible with different ways of managing messages. Conceptually, an invalid data point is different from a VTL program error therefore this distinction should remain in the way these two completely different concepts are described. A division by zero is a program error while a data point whose values are not conforming to certain validation rules is not an error. In addition: errorcode cannot be only a cryptic code errorlevel should have type string - not integer (e.g. Error, Warning etc.) See explanation in issue #331

errorlevel could be associated to a variable (dictionary, or code list) of error levels. See also issue #330

[bellomarini]

This is an example showing:

• error handling
• management of multiple check conditions

DS1

ID1	ID2	ID3	M1
----	-----	----	----
a	b	c	36
e	f	g	-4
h	i	l	3
m	n	o	-3

DS2 := check(
{mod(DS1,2)=0,  errorcode("ODD_NUMBER"));
DS1<0, errorcode("NEGATIVE_NUMBER");},
all
)

DS2

ID1	ID2	ID3	CONDITION	CONDITION_NUMBER	ERRORCODE
a	b	c	TRUE	1	null
a	b	c	TRUE	2	null
e	f	g	TRUE	1	null
e	f	g	FALSE	2	NEGATIVE_NUMBER
h	i	l	TRUE	1	ODD_NUMBER
h	i	l	FALSE	2	null
m	n	o	FALSE	1	ODD_NUMBER
m	n	o	FALSE	2	NEGATIVE_NUMBER

• CodeList for errors. Extensible code lists (partly general, standard and shared, partly specific).

• The same for ERRORLEVEL. The best would be to have it completely personalized, i.e., with no shared part.

• However ERRORCODE can be also free, without any associated code list. The ValueDomain is up to the organization (string, integer, enumerated, ... with code list).

• CONDITION_NUMBER variable is assumed to be present. A complete list of the variables that VTL assumes to be existing by default, to be clear.

CODE ITEM	DESCRIPTION
NEGATIVE_NUMBER	The number is negative
ODD_NUMBER	The number is odd
NEGATIVE_AND_IDD	The number is negative and odd

Standardized vs user-defined errors

1. syntactical errors
2. compile time errors (semantics)
3. runtime errors
4. validation errors (user-defined errors)

• We are not standardizing runtime errors. Their codes do not appear in the Dataset.

• The code list for errors is completely user-defined and is only for validation.

• There can be some runtime errors that can be checked as a part of validation (business errors), they will be associated to a user-defined code.

• ERRORCODE is free, and its value domain can be defined according to the needs of the adopting organization (string, integer, enumerated in a code list, etc.)

• What happens if I don't define ERRORLEVEL and ERRORCODE in the information model?

• Checking whether ERRORLEVEL and ERRORCODE are defined in the Information Model is implementation dependent, however, the check for this would better be in the semantic validation of the program.

• Errors of kind 1, 2. We'll face the problem to standardize them while developing a parser. We cannot produce it now. Change the manual: there are compile-time errors, of kind (1,2). Downgraded to a guideline for parse development.

Conclusions

• Update the user manual to explain what above.

Future work

• Error-handling runtime operators.