> On 07/21/2013 09:35 AM, D. Michael McIntyre wrote: >>> On the downside, assertions are crashes that cause data loss, but >>> only in a debug build. Is anyone seriously morally opposed to this? >> Nope. > > Ok, since no one has argued against allowing assertions in > rosegarden, it appears that they are now "officially" allowed.
OK. Thank you for following up on this. > I've added some guidance to the coding standards on the wiki: > > http://www.rosegardenmusic.com/wiki/dev:coding_style#assertions I have reservations about trying to recover when NDEBUG isn't defined. That itself is coding and debugging effort. ISTM it makes more sense to spend all of that effort on the underlying problem, so there's nothing to recover from. This is what we do now and it works. Coding effort is probably better spent on conditions that aren't thought to be impossible. But it brings up something I've been meaning to mention. I'm *not* proposing that we do this any time soon. I'm just throwing it out there as an idea. Let's say we do try to recover in commands, from should-have-been asserts or just from runtime problems, bad parameters, etc. After "if (p)" you still have to whole problem of how to actually recover. Right now, you have to execute some zombie version of the command, the user has to figure out what happened and realize he has to undo it, and then your unexecute has to cope with any damage that happened. We might want to consider an approach where a command can fail in "execute" by setting its own concerns back to their original state and raising a specific exception. That exception handler would be responsible for getting back to the previous stable state, other than undoing the specific action of the command. Fleshing it out a bit, that handler would probably live in CommandHistory. It might remove the command from history and explain what happened (delegating to some pop-up message or something). It'd be responsible for making macrocommands recover gracefully. Tom Breton (Tehom) ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
