Etherpunk

For what it's worth I've decided to re-focus on certain things.Two of the computer aspects are: OpenBSD and programming (C#, .NET 2.0 compatible code, but some is 3.5).I want to update the OpenBSD-Wiki and start making major progress on the MetaDataSystem. I've made good progress with it so far using SubSonic and SQLite. A few gotchya here and there though.The third thing is going to the gym more religously. I'm pretty reliably at going at least twice a week doing 3 body parts each day. The pattern is usually Back/Bi/Legs and Chest/Tri/Shoulders with at least a day rest in between.I think I'm going to switch that to Monday and Wednesday are workouts with minor aerobic while Tuesday and Thursday are major aerobic and swimming and relaxing in the spa. Sundays I'm trying to get out and swim at the local pool. Alochol is usually involved there. Saturday nights usually involve alcohol too... and be being an idiot, but that's half the fun isn't it? going "I just did NOT do what I think I did? FUCK!". Usually laughing about it the next day.

Microsoft provides a web page dedicated to checking basic net connectivity. You can find it here. I find it very useful for checking to see if UPnP works. UPnP is needed for Windows Live Messenger to do webcam stuff and OpenBSD is very much against UPnP, luckily someone wrote a page which helped get it going nicely. It can be found here.

So I had an intersting discussion with the guys at work about try/catches.

My opinion is slowly becoming: Try/Catches are habits of poor skill in programmers.

Sure, sometimes you need to use them merely to be sure. Or global try/catches *just to be safe*, sure, but relying on them -- I believe it's poor coding.

The argument they brought up was "so, what -- you're supposed to use if's for *everything*?" to which my response (now) is "what? you use try/catches in *everything* method?" -- which I know they don't -- and it bit us.

You see, in a DataGridCellMouseClick or some event simliar to that you can have it attempt to calculate what cell it's in. So, we had something like:

int SomeVal = Convert.ToInt32(DataGridObject.Cells[e.Cell.Row,e.cell.Column].Value.ToString());

 Sounds simple, right?

Well, turns out if you click on a column -- it barfs (either row or colum will be < 0 if you click them). So, ok -- to what extent do you do sanity check on data? It's awfully unreasonble to do sanity checking on *everything* *everytime*. So, perhaps you should just do it when you intiate it?

The net result was something close to:

if ( e.Cell.Row < 1 || e.Cell.Row < 1)

    /* Assume they clicked on a header column or row */

    return;

int SomeVal = Convert.ToInt32(DataGridObject.Cells[e.Cell.Row,e.cell.Column].Value.ToString());

Something I have learned while writing a migration app is that try/catches slow you down an amount that is not insignificant. A couple million times and you are looking at adding minutes or *hours* to your app. So not only have I learned this habit because it made my app much slower, I learned you should pay more attention to your code.

Perhaps slowing down coding to make code cleaner is a better idea. Think it through.

I found a few comments around the net about this too and it seems that some believe try/catches are so infignificant that you should use them freely while others will say that using a try/catch because you don't do proper parsing / variable handling just shows poor coding skills. A very common one is DateTime.Parse versus using DateTime.TryParse -- which I should use Int32.TryParse above (go figure).

On an important note, I do understand (and use myself) try/catches for play-pen type code. Things that *can't* faily, however, I don't allow try/catches. For example, migrations -- they *can not* fail. Ever. Peroid. Hitting a try/catch means *I* fucked up somewhere or someone pulled a network cable (which I need to research how to check for that anyways).

Stock HP Pavilion Ultimate d4999t:

Ok, so apparently it only displays properly in IE... that's fucked up.

update: Also doesn't display in Firefox 3 Beta 5. I'll investigate why.... merely just to know.

Linky

That is a pretty funny link.

SSE (SQL Schema Export) is used to export tables and views in a diff friendly format.

SQL Server 2000, for example, does not seem to reliably export tables in a perdictable format making diff comparisons a pain.

mBlog's is to be an open sourced basic document writer app that can speak the many forms blogs will allow.

MetaDataEngine has been called many things since it's initial startings.The primary goal is to have a portable OS (SQLite) to store logical or physical objects (e.g. code keys [meta data] for software or perhaps meta data for pictures (such as 'Christmas,2006,family') in the form that most people know as 'tags'.

A program meant to parse an XML file and ask questions and have the answers actually be semi-related to the question.For example, if you want to learn how to count in Spanish you wouldn't want colors coming up in that quiz.