Future Random Number

OK, my fellow geeks. I need a hand here. (Non-geeks welcome also.)

I want to specify a random number that will not be known by anyone (including myself) until a given date. That way, I can publicly say that I will use this random number, and everyone will know that I have no control over it, and when I use the number, it will be easy to verify that I am using the number I said I would. Confused yet? Let me give an example:

My only idea so far is to say “the random number I will use will be the result of multiplying the closing stock value on 31-December-2004 of every stock on the NYSE, the result being truncated (floored) and modulus 1000″. That should give me a nice relatively random number from 0-999. The problem with this idea is that I don’t know an easy way to get this information. And there might be too many stocks on the exchange to make this practical. I’d like a number that is a little easier to verify.

To summarize, I need a number that will be:
1) unknown (non-existent) until a given future date that I can pick in advance
2) obviously not influenced by me
3) relatively random (a decent distribution over at least 100 possible values)
4) easy to verify

Any suggestions?

Posted by Jeremy on August 30, 2004. 13 Comments.

Herdsperson Wanted

I noticed a classified ad today:

HERDSPERSON
wanted for Syracuse area
dairy. Ability to manage
people and cows.
References required.
315-673-1941

Posted by Jeremy on August 29, 2004. 1 Comment.

Exceptions in the finally block

My apologies to non-programmers. Today, I have something to say about exceptions that are thrown in the finally block…

conn = new Connection(...);
try {
    // database operations
} finally {
    conn.close();
}

Now, suppose some database operation in the try block throws an exception. Before that exception is propogated to the caller, the finally block is executed. In my experience, it’s common for a failed database operation to prevent the connection from closing normally. Thus, conn.close() itself throws an exception. Which exception is received by the caller? The original exception or the close exception? Unfortunately, the close exception is propogated, masking the original exception (the only one we really care about).

So, here’s what I’ve often done in the past:

conn = new Connection(...);
try {
    // database operations
} finally {
    try {
        conn.close();
    } catch (Throwable t) {
        // Ignore it to avoid masking original exception
    }
}

And that has worked fairly well for me. However, in a recent project, we noticed that we were receiving an error closing a connection. The code was similar to the first example above, so I changed it to be like the second example, so that we could see the original exception. The result? No exception was thrown.

Uh-oh. So, in the case when nothing else goes wrong, but the connection can’t be closed, I’ve completely hidden that failure. What should I do?

Option 1: Write complicated code

conn = new Connection(...);
Throwable finallyProblem = null;
try {
    // database operations
} finally {
    try {
        conn.close();
    } catch (Throwable t) {
        finallyProblem = t;
    }
}
if (finallyProblem != null) {
    throw finallyProblem;
}

Yeah, that’s a bit excessive.

Option 2: Log it

conn = new Connection(...);
try {
    // database operations
} finally {
    try {
        conn.close();
    } catch (Throwable t) {
        log.warning(t);
    }
}

Yeah, I guess that works. But how often do you check your logs?

Option 3: Rationalize away the problem.

This is my favorite option <grin>. Stick with the code that discards the exception in the finally block. Theoretically, code that releases resources should not throw an exception. Ever. It makes it very difficult (impossible?) to create exception-safe code if you can’t make that assumption.

Posted by Jeremy on August 13, 2004. 2 Comments.

Pork

For dinner, yesterday, we had pork. As we were eating, I glanced through the mail. My state assemblyman, Joseph Morelle, had sent out an update bragging about his accomplishments in Albany. It looked like he had pork as well. Here is the money he “secured” for Rochester:
$5,000 for a playground
$60,000 to light a Little League field
$10,000 for a sports program
$50,000 to improve safety in the homes of elderly
$50,000 for a new museum exhibit
$75,000 for a film festival

Fiscal responsibility in New York state is a joke. We complain about the high taxes, but then we want to make sure we get our fair share of spending.

I guess I can understand my assemblyman’s position. If he wrote a newsletter that said “I turned down all my contituents’ silly requests for grants to help keep down taxes”, it probably wouldn’t go over so well. Particularly since it wouldn’t be true. Taxes would still be high since all the other representatives are “securing” money for their areas.

I think I’d almost be a Libertarian if their morals weren’t so… well, libertarian.

Posted by Jeremy on August 6, 2004. 1 Comment.

Email notification

I think there may be a few people who would actually like to read the gibberish I publish in this online journal. (Well, OK, maybe just my mom.) But, I had a problem: those people don’t know when I post a new entry. Cool people like Mark use RSS readers, but most of my readers (i.e. Mom) have no idea how to use my RSS feed.

Today, I finally found a solution to that problem. I now have a subscribe form! Thanks to the plug-in from Brian Groce, you can type your email into the form on the left nav to receive a notification whenever there’s a new post. (This site has changed since I wrote this.)

Posted by Jeremy on August 4, 2004. 2 Comments.