Nothing I said would have prevented you from logging the exception and re-throwing it.

try
{
throw new ArgumentNullException();
}
catch (ArgumentNullException ex)
{
if (ExceptionPolicy.HandleException(ex, "DefaultPolicy"))
throw;
}


If you want to change the exception thrown, that's fine and dandy.

try
{
throw new ArgumentNullException();
}
catch (ArgumentNullException ex)
{
if (ExceptionPolicy.HandleException(ex, "DefaultPolicy"))
throw new CustomException("Something bad happened", ex);
}

These kinds of blog posts seem to turn up every so often, with the writer eager to point out a flaw where there is in fact none, at all.

The *only* reason that one should throw a new exception is in the event that it be necessary to change the type of exception that was thrown to something more meaningful for the intended operation. In *this* event, it should be considered a good (though not necessarily "best") practice to pass the original exception to the inner exception parameter of the new exceptions constructor. If intentions do not include changing the type of exception, there is no reason to do anything other than throw the original exception with throw.

Anastasiosyal and offwhite, make no mistake about it, exceptions can and will occur in production applications. Unless your application targets a room full of developers with a debugger at their finger tips, you should have no expectation of having a debugger to assist you with debugging, for example, a problem that seems to occur only a clients machine. The more information that your clients have to report back to you, the easier your life will be with determining the proper way to correct the issue.

Cool! Thanks for the info.

Wait a minute. I just read the following:

"we're providing a location, install dvd's (these will be evals because the finals aren't pressed yet), and food/drinks. "

So we'd get an eval copy of Visual Studio 2008? What good is that?

Maybe I should learn how to read before I post. I just found the complete link.

http://timheuer.com/blog/archive/2007/11/27/get-visual-studio-2008-professional-for-free-installfest.aspx

Too bad there aren't any events on the east coast (preferably Maryland or Virginia). Just too far for me to justify.

I like the gist of article, but I would have titled it differently. Admittedly, I'm not really sure what I would have titled it, but it's not really about writing software per se, but more along the lines of designing an application. Hopefully that made sense (actually, does it really matter?) If you haven't already noticed, my brain is a little fried from this week and I'm essentially just rambling endlessly!

Interesting. I don't use Team System so I've never seen this, before. I've definitely seen it in SubVersion, however. ;)

Well cool! So simple, yet I never knew that.

Read this...

http://www.dotnetkicks.com/clr/Why_Not_To_Catch_General_Exception_Types#comments

+1. I posted this a while back, but I still refer to it from time to time. Definitely worth the read.

This is one of the most ridiculous posts that I have ever seen on this site. It's nothing more than a pointless rant.

What I do to circumvent this issue is wait until I'm [near] complete with my code before adding regions. If later, I have to add a new method or something, it's really not a big deal to cut and paste the code and put it into the correct region.

Knowing that unmanaged applications were trusted by default (as the intro points out) I never understood why unmanaged applications weren't trusted, by default.

I have yet to have a valid use for Server.Execute(), so if anybody has any good examples, I'm all ears.

I'll openly admit that I hate JavaScript with a passion. I'll take as little of it as possible. But even still, I have found myself still ocasionally writing something in JavaScript.

As far as no longer understanding XHTML, CSS, that's completely untrue, in my case. I follow strict XHTML standards and implement everything in CSS. I'm certainly not as good as some people, but I'm a developer. That's what designers are for. It's nice to have the blend of talent and I make every attempt possible to stay current with designing standards; however, my true point in the programming world is doing development --I simply lack the artistic abilities required to be a good designer. Be it web development, some kind of service, or a desktop application, I find my energy is best spent on programming and leaving the designing to the designers. And if somebody thinks less of me for not having to write JavaScript, fine, but at the end of the day, let's compare the amount of work, that I got done with the amount of work that they got done. Development has always been about reusing code that has proven itself in the industry and I have had zero issues with the JavaScript that Microsoft has already written for me. It keeps me focused on the real problem at hand instead of worrying about all the plumbing involved.

I recommend avoiding Server.Transter( ) in nearly all situations. I've seen people save almost an entire form in context and then read the values back on the new page. This is a horrible idea because it ties the second page with the first page. I have no problem with one page complementing another page (e.g, passing search criteria in a query string to the next page), but if one page absolutely relies on the previous page (e.g, saving the value of every control into Context and reading it back on the second page) you're better off just using panels that are hidden and displayed when appropriate.

On that note, one good use that I have found for a Server.Transfer() is when transferring to a summary page after, for example, a user has made a purchase. This prevents the user from hitting the back button and having their credit card charged twice. Other than that, saving a single additional request from the client, there isn't much else I have found to gain, but a lot more to loose.

In my not so humble opinion, it's almost never a good idea to break browser URL's. And no, URL rewriting is not the right answer --it's another hack that is very specific to the implementation. Also, I've run into situations where developers have used Server.Transfer() for every single request. This ends up breaking the browsers back button and frustrates users, which is also not a very smart thing. Lastly, every developer that I know that makes exclusive use of Server.Transfer() ends up making the mistake of saving [nearly] every control value into context before transferring and then reading the values back on the new page. Any time you update either page, you have to make sure you haven't broken anything. This is just silly and should definitely be considered bad practice.