My Tales

2008-07-30

stack overflows will STILL call the finally

package test; public class miscTest { public int loop(int x){ return (loop(x+1)); } public static void main(String[] args) { try{ int x=0;int y=5; miscTest test = new miscTest(); test.loop(1); double t = y/x;

	}catch(Exception e){
		System.out.println("catch start");
		int x=0;int y=5;
		double t = y/x;
		System.out.println("catch end");
	}finally{
		System.out.println("finally");
	}
}

}

finally java.lang.StackOverflowError at test.miscTest.loop(miscTest.java:8) at test.miscTest.loop(miscTest.java:8) at test.miscTest.loop(miscTest.java:8)

2008-07-30

morry:
where are you supposed to put the code? Magic fairy blocks?

That's actually a genious idea. I propose this as an addition to the next version of the .NET framework.

try {
    doStuff();
}
finally {
    semiCriticalTransactionCode();
}
magicFairyFinally {
    // Will ALWAYS run, even if the machine has no power
    criticalTransactionCode();
}

2008-07-30

It depends on the language evidently because it doesn't with C#.

class Program { public static void Main(string[] args) {

		try
		{
			Console.WriteLine("Attempting to access property");
			int x = Number;
		}
		catch (Exception ex)
		{
			Console.WriteLine(ex.Message);
		}
		finally
		{
			Console.WriteLine("Finally block run");
		}
	}

	private static int Number
	{
		get { return Number; }
	}
}

Output

C:>TestApp.Console.exe Attempting to access property

Process is terminated due to StackOverflowException.

C:>

tgape · 2008-07-30

Morasique:
BentFranklin:
Someone please educate me a bit: How does a database survive a power cycle in the middle of writing a transaction?
Captcha: appellatio (A program that sucks?)

Usually databases use journaling...

This is part of the answer, other posters have also given partial answers. For a more complete (and low-level, while still remaining generic) answer:

A good database will arrange its write operations such that the difference between having not entered the data and having fully and correctly entered the data is a single, atomic (meaning, it can't be interrupted by anything short of a hardware failure - and generally, even a power failure will allow it to complete) operation.

This is normally a very difficult task, especially if the database supports 'transactions'. Most modern databases use journalling, which makes it much easier (note: the below skips locking and parallelization, which would needlessly (because this isn't actual code) complicate the answer):

You write what you are going to do.
You update the journal end marker (a single, atomic update) to cover the new data.
You update the database data for all of the operations involved.
You update all the database indexes for the new data.
You update the journal start marker to not include that entry (a single, atomic update)

Now, there's two atomic updates there that have critical effects, rather than just one for a pre-journaling version. However, there's no need to dance around making dozens to hundreds of changes such that they don't take immediate effect until some later update occurs, because if it fails at any point after the journal is extended to cover the new update, the database will know exactly what it was trying to do, so can finish it up on restart. If it occurs before step two, then the operation never happened at all.

Of course, on error, there's also rollback, as others have mentioned. I think that's been adequately covered in other posts, however.

My Tales

Finally!

The “Qualified” Candidate

Featured Comments