Re: [Audacity-devel] Bug 137

[Edgar <edg...@wa...>]

Martyn Shaw-3 wrote:
> 
> I saw a message recently that we should 'store up' errors so that 
> users don't have to press an 'OK' button to a 'file write error in 
> SimpleBlockFile 2' (etc.) every time it happens (like we do now). 
> That is a good idea, even if we actually terminate the process causing 
> the errors (in case we do it again).
> 
> it will be difficult to maintain the code that you have changed, 
> unless it is all easily identifiable.  One option would be to wrap it 
> all in EXPERIMENTAL, see Experimental.h.  That might be a good plan. 
> I could commit it, then turn it off again in a moment, + it would all 
> be easily findable.
> 

Storing up errors like these is an extremely bad idea. The very first one
makes the data in the Project "bad". The only reasonable solution is to trap
the error (notifying the user of the specific error), do the appropriate
recovery (e. g. in a SaveAs Project roll back any already written AUs and
the AUP if it is partially finished, delete the empty _data folders and
notify the user that the SaveAs failed). This is the code I have presented
in discFull but conceptually it is way too involved for pre-2.0 unless a QA
decision is made and major Developer support exists.

Every change is wrapped in "//efm5 start" / "//efm5 end" or, if a single
line or two, is identified with efm5. "efm5" exists no where else in the
code. It would be a matter of a few minutes work to remove (or find those
areas which need extend-to-recovery) all this code having the original patch
as a reference. This code is not experimental and wrapping it in such would
be a chore and waste of time. Feel free to make that change or any other.



--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-137-tp6614577p6647674.html
Sent from the audacity-devel mailing list archive at Nabble.com.