theRAPTLab / gsgo

GEM-STEP Foundation repo migrated from GitLab June 2023
1 stars 1 forks source link

INFRASTRUCTURE: Logging System Basics, Error Manager Libraries - [merged] #706

Closed benloh closed 1 year ago

benloh commented 2 years ago

In GitLab by @daveseah on Jul 27, 2022, 15:47

Merges dev-sri/system-updates -> dev-next

(incorporates !257, which can be closed if this succceeds)

This merge request adds to major infrastructure systems: Event Logging and Error Management supporting code. These features have not, however, been activated anywhere in the codebase. Both these feature require surgical placement in the code, and is best handled in a careful pair programming session.

TESTING

With luck, this merge request doesn't change anything in the existing projects, as it just adds some features that are not yet used. There are some cosmetic fixes here and there, and MAIN will now throw up a big error overlay so users know the system crashed before it could even draw anything.

NEW: EVENT LOGGING

The system event logger that is part of URSYS has been hooked back in with a new call UR.LogEvent('eventName',itemsList).

The logged data goes into the gem_srv/runtime folder and is tagged with the UADDR (address) of the webapp that is sending the log. The line begins with the UADDR and eventName, and is followed by TAB-DELIMITED items. This makes it easy to copy/paste into a spreadsheet like Excel and have the fields line up. The delimiter character can be changed to whatever is necessary, though be aware that choosing ',' means that you will have to make sure your itemsList strings don't have commas either.

NEW: ERROR MANAGER

The error manager has not been able to be merged until now because the approach it takes requires a careful structured of how errors cascade throughout the system; to have done so earlier would have broken the prototype for the workshop because it was handling errors in a different way.

Currently the error manager is now back in the library. It's enabled for Main when it is calling PROJSERVER.ProjectDataPreInit(this, projId) to detect bad project files and pop-up an alert to let users know something is wrong.

In all other cases, error catching traps are in place, but are commented out. The affected modules are:

This is not a complete trap strategy, but is good enough to start the discussion on how to trap errors in a way that they can be reported by the GUI. One error can cascade through the entire system under very different contexts; is a script error occurring during compile time or runtime? Is it a script defined as an initScript or roundScript causing the compiler to crash? Is the error due to a missing symbol or syntax error? This will require considerable guidance to outline the system in terms of user operations mapped to underlying technical pathways so we know where to insert the error traps.

OTHER MISCELLANEOUS FIXES

benloh commented 2 years ago

In GitLab by @daveseah on Jul 27, 2022, 17:56

added 25 commits

Compare with previous version

benloh commented 2 years ago

In GitLab by @daveseah on Jul 27, 2022, 19:00

added 2 commits

Compare with previous version

benloh commented 2 years ago

In GitLab by @daveseah on Jul 27, 2022, 19:04

marked this merge request as ready

benloh commented 2 years ago

In GitLab by @daveseah on Jul 28, 2022, 10:04

added 1 commit

Compare with previous version

benloh commented 2 years ago

QA Testing Log

Jotting notes on testing for future reference.

CAUGHT

Errors clearly caught by the existing Error Manager, showing an error on the Main screen.

NOT CAUGHT

These are not necessarily problems...just noting where Error Manager is not catching stuff.

OTHERS

benloh commented 2 years ago

Tested opening and running and editing multiple projects. Things seem to run for the most part, so merging.

benloh commented 2 years ago

mentioned in commit 977e2cdcaa145c1c253c348be74f1878e668593e