The ERRORMODE in Qlik and the belonging error-variables aren't an error-logging else you may consider them as a starting point for an own error-handling. For this you may create one or more sub-routines which are centralized outsourced and per include-variables available and then you may call these routines whenever you need them.
It sounds like some efforts and it is but as far as you don't want just an error-logging else an error-handling which branched into multiple different measures like repeating certain tasks n times, then doing this, that and in end do anything else - you will need to specify all this stuff.
Personally we don't use ERRORMODE in a regular way else only very rarely in specific scenarios and don't have such mentioned extended solution developed. I really thought several times if it would be sensible and helpful for us in any way but each time I made the conclusion that we don't need it - regardless how many time/efforts it may cost.
There are various reasons why we decided us against such logics. Mainly we use a multi-tier data-architecture and have therefore a lot of applications with rather less scripts and tasks and if there are any errors it's usually very obvious what caused them. Further it's rather seldom that we had really options to do something sensible - if a server-connection, database, file aren't available and/or not up to date we couldn't change it else we provide the data which are available (usually those until yesterday). If a generator breaks here and runs into an error the following datamodel + reports aren't really touched from it - they just run with older data. If certain things starts to happens more often we tend to react directly like implementing appropriate checking within script before letting the script to run into an error and/or removing the task from the belonging task-chain and scheduling it separate and similar measures.
Beside this we are usually quite close to our data-updates and the reporting and could fix most of the issues rather quickly - often without the users notice anything because we are further within the target time-frames. Of course in bigger environments with much more involved people and a more or less strict division of work between data/application-development and administration and smaller time-frames and system-resources it will be more difficult to run such environment successfully.
But IMO to log errors and to react on them may be helpful but is not so important as to avoid the errors in beforehand and therefore I would suggest to concentrate the efforts in this direction.
Nevertheless you may look within the easter egg and check if enabling options like ExtendedErrorLoggingMode and/or ExtendedErrorOutput and/or other settings may provide more insights. I assume that there are good reasons why these options aren't normally available, for example I could imagine that they may have a significantly impact on the performance.
- Marcus
