Ugarit
View Ticket
Login
Ticket Hash: 4363bc76315d082f4d82f01d543fa5562ff6109a
Title: Audit error handling
Status: Claimed Type: Feature_Request
Severity: Cosmetic Priority: 1_High
Subsystem: General Resolution: Open
Last Modified: 2013-01-04 14:08:12
Version Found In:
Description:
The handling of exceptions in Ugarit is currently naff.
  • Hitting ctrl+C doesn't abort an in-progress snapshot, as it's caught and logged as a per-file error.
  • Unsupported feature errors (due to not having an optional egg installed then trying to use SHA2 or whatever) are displayed in a horribly ugly way.
  • The front-end generally lacks exception handling, except in a few specific places

In general, when walking any kind of tree (both snapshot and extract), we should raise errors as a continuable exception. The frontend will then install a handler that prints a warning and continues, or prints an error and aborts if a suitable flag is set. Then we can remove the exception handling in the core, and have it purely in the frontend.

The frontend should wrap an exception handler that prints exceptions nicely around the top level.

^C should be handled specially by printing a suitable message and aborting.


alaric added on 2012-06-11 15:24:15 UTC:
When extracting a file, if an error comes up, we will abort that file and leave it partially-formed on disk.

We should perhaps delete it, or perhaps rename it to something suitable so it's not opened by mistake, and if the latter case, write a marker where the missing block would go and then proceed to the next block. We won't know how many bytes are missing, but we could try and recover all we can and write "[--- UGARIT COULD NOT EXTRACT SOME CONTENT HERE ---]" in the gap.


alaric added on 2012-06-12 12:49:14 UTC:
Still to do: test the ^C handling code under more recent chicken to confirm that the signal handling bugs in 4.7.0 that made a ^C have to be done twice to take effect actually work.