why throw the exception?

i've got a try/catch block that basically goes something like this...

try
{
 // try to do something that may not work...
}
catch (Exception error)
{
 // take the exception and put the info into a database so i can fix it later...
 string strMyError = Convert.ToString(error);
 //...
}

now, the book i'm using says to add thethrow keyword at the end of the catch block, but it doesn't really explain why...

my code works either way, what really happens when you throw at the end of a catch block? if you could, please be specific with details, i'd really like to understand this, and this book (ironically, a book written to study for the MCAD exams) doesn't even explain what it does...

//...
catch (Exception error)
{
 //...
 throw; // why?
}

hi...
i duno why ur book said so..if i ever wanna throw an exception in catch is to define my own exception for example i have an SQL exception thow to me then i catch it..in my catch block i wanted to thow another exception say my very own exception and customise my very own message handling so that when it display to the user is rather readable and at the same time i can also add more custome message like my Sql statement or what so ever message.

eg

catch(Exception err)
{
thow new MyCustomException(err,CodeID,"SELECT * from SQL",Friendly User message);
}

i duno if i had answer ur stuff but that is what i do...
Well,

You might want to take compensatory action - or some exception specific action at least in the individual 'low level' handler for a class.
Then you may want to throw the exception to a higher level handler - say at the Application layer to provide, for instance, more general exception reporting to the user.

Re-throwing an exception effectively bubbles up the exception to the next layer.

HTH
Throw returns info about the exception. For example you can define a number of different exceptions in your code and throw(return) information about the specific exception to the debugger or the application.
FromRich Custom Error Handling with ASP.NET:

"Before going on, note that there is a school of thought that says you should always throw an exception higher, that "swallowing" the exception is a bad idea. The reasoning is that exceptions should be visible and logged so that they can be guarded against in the future (with improved infrastructure, scalability, and so on), and that any instances that might be swallowed could be avoided with better programming. This happens to be true. Swallowing an exception is fine while debugging, but production code should always throw exceptions higher. Then, whenever preventable exceptions show up in the logs, you can apply some validation to ensure they won't happen again."
Well put SNK2.

It may be overkill, but we write to the servers application event log from our Try Catch as well as a secondary method using the Global.asax.vb Application_Error event that sends an email to the entire IT Dept with all the information related to the error as well as who was using it when the error occured. Being able to interface with the user as to what they were doing when the error occured can lead to a faster solution, unless of course it something obvious.

When one of my guys deploys a piece of code and it starts bombing out and everyones mailbox starts getting flooded with emails, it creates a sense of urgency because it makes you look bad to the other developers and youwill get heckled. We all have had small things pop up that requires a "geeezzz, I can't believe I did that! I'm really not that stupid guys, I swear!!!" Great laughs, but it's very affective in managing and preventing errors.