microstream-one
Option for non-fatal exceptionhandling
Currently, every exception encountered on the storage-level (loading and storing entity data etc.) causes the storage channel threads to cease working. This is intentional to immediately disable any more changes to an existing database once an inconsistency is detected.
However, microstream-one/microstream-private#35 introduces another usage mode of the storage level. While so far, only valid objectIds could ever be requested and any not resolvable objectId must be a fatal inconsistency, a "viewer" should always be seen as a harmless querying tool and should NEVER have a fatal effect on the actual database.
Example: The web interface user changes the objectId requested via the URL manually to a non-sensical value. Currently, this causes the storage to shut down "in panic" while actually, it should only return a "not found"-like response.
Even if a web service tool should issue writing tasks in the future, a problem encountered while executing them should only cause a rollback of any changes (already implemented), but then not a shutdown in panic, but a continued processing.
Replacing the StorageExceptionHandler would work, but wouldn't be a good solution. A) Because it would require the production storage logic to be modified just to allow the usage of a viewer B) It would suppress actually fatal exceptions in production mode, too.
This means that tasks must be issueable with a kind of "severity" metainformation. Decided by the StorageConnection or the PersistenceManager instance. All production code would keep issueing high-severity tasks, while a simple viewer would always just issue tasks with ignorable severity. Of course, all state must still remain concistent, i.e. a failed write must still cause a correct rollback.
