Etherpunk

Like I said before, I really dislike try/catches. They slow your code down and they are generally used when you don't know how to appropriatly handle data. For example, using try/catch to convert a string to an int versus using Int32.TryParse(). Yes, I've really seen this on the wild... and not from an amatuer either. I'll openly admit, I'm an OK programmer. I have much to learn. I just learned how to implement Transactions in code. I have learned how to make .NET crash so hard -- it throws an exception *outside* of your applications domain. This means you can't catch it. At all. But I'll get to that in a minute. I'd like to start by explaining when it's a good idea to use a try/catch.

Using try/catches are a good when you can't calculate everything. For example, network issues. Sure -- you can ping a server. Doesn't mean the database is up. Sure, you can do many other things such as test the database (SELECT 0 comes to mind) however you can't calculate the network being dropping in the middle of everything. So far the only method I've found that is reliable is using a try/catch because the medium is so volatile, even after doing your check it can go down. So, the answer is to use a transaction (if you are doing multiple inserts) and using a try/catch looking for a SqlException. But this won't stop everything... I'll explain how I pissed off .NET with pictures and network failures.

Apaprently .NET handles System.Image in an intersting way. It is only a pointer/reference to the location of the file. What this means is that if you reference an image across the network and it goes down -- System.Image throws an exception. In fact it throws a pretty gnarly exception that you can't catch. Here is how you can reproduce this. Create a blank project. Drop in a timer and set the interval to 15 second or an amount that a little longer than it will take you to unplug your network cable. Modify the form load to engage the timer and have the form load the image. Have the form hide itself. On the timer tick, have the form display itself (this will cause the image to be repointed and thus having to look at the network to pull the image). Start the app and then unplug your network cable. It should have a nasty crash. One you can't stop. Another thing I learned is that it puts a lock on the file so you can't delete/modify it. So far the only idea I've come up with to have an in-memory cache is to load it in to a byte array from a stream and have you rference that byte array. What I don't know is if it's still a pointer to the file. I might assume that that stream will push the bits in to the byte array and thusly remove the dependance of the network.

Using SubSonic the code to implement transactions and SqlException is pretty straight foreward and you would just surround your .Saves (personally, I like to place everything in the try/catch block just to make the code look cleaner) with a System.Transactions.TransactionScope. A TransactionScope will put a lock on your table when doing an insert, and for good reason. This is because you can't rely on the data to be inserted until you do a commit. So this will stop people from seeing the data (or any in the table for that matter) so they don't reference it and then have the transaction cancelled and then you have an inconsistant database. If you want a way around that then you should use System.Transactions.TransactionOptions. TO has only two properties -- timeout and the scope options. Microsoft has an article explaining the enumerations and their values and which ones you would want to use for which circumstances. I should probably link it but I'm too lazy.