Andre Poenitz wrote: >> > Writing the emergency file is only part of what I want. I also want to >> > present the user with a dialog telling him about the error and giving >> > him the option to continue at his own risk. >> > >> > There is absolutely no reason to abort if i.e. s&r or loading of an >> > icon failed. >> >> s&r what? > > Search and replace.
I mean, we don't assert normally when the search string is not found (now that's an idea!), there's surely something worse happening. >> It may be that failure of loading of an icon has no consequences, >> it may be that it leads to memory corruption, it depends on details of >> how the code is written. Same thing goes for some s&r assert failure. > > Let the user choose. The user can choose to rerun the program anyways. >> And in any case, that's still fine by me. I'm only saying that if the >> choices are a) abort on all current asserts and b) ignore all current >> asserts; then my choice is a). I don't think the dialog is really useful >> for me. If the emergency file is written, then clicking "continue" will >> be equivalent to rerun lyx and reload file (C-R lyx in the terminal where >> I started lyx normally), clicking "abort" equivalent to doing nothing. >> It's not that I have anything against it either. > > Even DOS had "Abort/Retry/Ignore" and gave you the possibility to insert > the correct disk... Not really the same isn't it. cp is a simple program that relies on system calls; it wasn't aborting after detecting some inconsistent internal state like it's our case in lyx, it was just reporting a well defined physical io error as returned by the system call. I don't see how continuing after detecting an inconsistent internal state could be really useful (specially for cp) A/
