This has been inspired by researching an undocumented error message for the Open-Command where we have invested much time to search for the cause of the error which could have been prevented if the error message was meaningful and documented e.g. in the scrioting index.
In fact we got the error "Cannot open table at row <n>" several times but not reproducible while opening CSV files using the Open-Command. After a long research we have seen that the sometime file copy actions of huge files via the network take a long time and in case of an unstable network get abandoned after a timeout. This means a part of the file content could be transferred but the other part not and will be filled up with Null values.
I would like to see an improvement in these unmeaning error messages by:
- transferring them to meaningful messages "Cannot open table at row <n>" => e.g. "File is corrupted and cannot be read at line <n>"
- document it at least in the scripting index by giving examples in code
- make the text of the error message language independent in English
- returning language-independent error numbers like in the Windows-world e.g.
- a function exception_code() which returns an array of a error number and a language-independent error as a string { 93, "File not found"} or similar. This would be great to query the error code and present a custom message to the user.
This idea is important to lower unnecessary research times for error messages and enhance the prevention and taking care of errors.
@martindemel