Jim Henderson wrote:
> Well, sure, but dealing with every possible and conceivable exception 
> gets into areas where even in professional development it's decided not 
> to go. 

No, I  mean you can make it generic. Instead of looking at each of the 
30+ possible causes of error, you can say "Any error rolls back the 
changes."

You don't write a database transaction and say "What if the power fails? 
What if the process is killed? What if I run out of space? What if ...?"
Instead, you just build a transaction, and if anything fails, you roll 
back the transaction.

That's what I'm talking about. Then you don't have to build things like 
"check the package database against the file system to make sure it's 
consistent."

> FreeBSD != Linux, but you knew that already. ;-)

Except this error has been out there since UNIX v7 at least. But you 
knew that already.

> Well, yeah, that would fall under the category of "handling the 
> exception", no? ;-)

Not really. It's correcting an error you detected. If the error 
correction step also fails, you're pretty screwed.

For example, to make things work, you need to up date the executable and 
three dynamic libraries. You update the executable, and one of the 
libraries, and then your network connection to the machine hosting the 
files fails. You can't handle that exception by rolling back your 
changes manually.

> Sure, and as I said, I've had that happen to me - didn't need to 
> reinstall the system, had to clean a few things up, but this sort of 
> thing can happen with any OS, not just Linux.  Ever try writing to the 
> Windows registry with C: full?  (I knew you were waiting for me to bring 
> Windows into the discussion - there you go. ;-) )

Well, yes. That's why you have file system transactions in Windows. 
That's kinda exactly my point. If you start a kernel transaction, copy 
some files, update the registry, then bomb out, your changes get rolled 
back automatically. Just like any other database system, and regardless 
of why you bombed out or over which network the files are mounted.

> So you need to run a validation - but again as I've said a few times, my 
> experience has been that an *error* condition like you describe stops the 
> upgrade process, it doesn't silently say "well, that's OK" and continue 
> without notifying the user.

Unless the error is "you pulled the plug" or "the RAID fell over" or 
something like that.

> "in spite of failures" - huh?  Update a system by writing files that 
> cannot be written because of a full disk (say) even though the disk is 
> full?

No. Not having half-written files caused by the disk being full. Or 
having only (say) two out of file files updated because the disk got 
full while you were writing the third file.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message