Q:

Differences between `throw` and `throw new` and exactly how exceptions "bubble up"

Can someone please explain the differences in C# between:

throw
throw new

and exactly how exceptions "bubble up" as I've heard they do? 

In my daily job, I've used just try/catch to mostly control the flow.  I've divided the code into various "blocks" each one enclosed in a try/catch so I could log and debug exactly where a program crashed/had a problem, if there was any. 
In researching, I've found there is a "bubble" logic behind the exception - which is used in more structured software development.  For example, if I have a system in which I build modules/plugins/complex complementary classes, I might want the exceptions to point me to exactly where the code failed, OR, bubble up to a more generic part of the program to do a wider debug. 
The way how we can do this sort of "bubble up" exception catching, I do not know, but is my understanding correct?  Can someone perhaps give a clearer explanation of C#'s "bubble up" exception behaviour? 
then about throw:
I see there is throw and throw new. 
From what I've seen, throw is used when you check for a particular error/condition in your code and you want to warn the outside block that particular condition occurred. 
Is this correct?  I don't really understood why I have to use throw or throw new and the differences between them. 

A:

When an exception is thrown, the framework will walk up the call stack until it finds an exception handler that handles the type of exception you threw.   If there is no such exception handler, the program ends.   So you can provide an exception handler anywhere in the call stack where it is convenient to put one. 

In general, exceptions should be used for situations that your code cannot do anything about or recover from without user intervention.  If your user provides a file name that does not exist, for example, your code cannot read the mind of the user to get the correct file name, so it throws an exception. 
The difference between throw and throw new is that throw new throws the original exception, while  throw is used when you want to catch the original exception, do something with it (log it perhaps), and then rethrow it so that it continues to bubble up the call stack while preserving the original stack trace. 
Generally speaking, you won't usually need custom exception classes unless you want to do something exotic like serialize your exceptions or capture specific data during the throw new (for diagnostic purposes). 
An Interface has but one purpose: to decouple an implementation.   There are many reasons why you might want to do this, but they all amount to essentially the same thing: having the ability to provide multiple implementations that conform to the same interface specification. 

A:

So, first things first, programming language features and computing concepts in general are just tools.  Your question indicates that you don't really seem to think this way.  You think of needing to do something first, and find some pattern of code accomplishes that.  I cannot stress how strongly how much this will limit your abilities as a programmer in general, and your career specifically.  
I am going to explain exceptions from the tool side.  Here is what they are.  Here is how they work.  Understanding the implications of that, and creating new, interesting, and wonderful stuff from them becomes your job. 

now I need something in the style "Explain it like I'm 5" for exception throwing. 

As your program executes, it progresses from one function to another.  This eventually builds a path from the entrypoint to the current execution point in the program.  The code itself is largely unaware of what function called it. 
This leads to problem when things go wrong.  When things go wrong in a function, it doesn't know who called it, so it doesn't really know what to do.  Enter exceptions.  Exceptions are there for the function to say "oh shit, something went wrong!  I don't know what to do!  I hope the stuff that called me knows what to do...".  
What happens is that a function throws an exception, and then the computer goes back along the path of execution that the program built up until it finds some function that actually knows what to do.  If no function is found, the OS generally just kills your program because something went horribly wrong. 
That's exceptions in a nutshell. 
In C#, the throw statement is how you tell the function to fire off that exception and go back along the execution path.  The common usage of the statement takes an Exception object as an argument.  Since you almost always have a new Exception, that's why you use new - just like any other object. 
catch is how you tell the computer "I know how to deal with this sort of error if it happens here".  
There are some other nuances around try/catch in C#, and other languages have some variation in how they work, but that general concept is fairly ubiquitous. 

A:

The purpose of an exception is: To halt execution because an error occurred and you cannot do the next operation. 
The purpose of catching an exception is: To retry if possible or do whatever other corrective measures you may in the event of the given error scenario your application is in. 
in C# an Exception is an object which:

Inherits from the System. Exception class
May be instantiated just like any exception by writing new WhateverException();
May be thrown with the syntax: throw instanceOfAnException;
May be caught with a catch statement that specifies the type of exception or any base-class that exception inherits from. 

Since all exceptions inherit from System. Exception you can catch any exception with the clause catch(Exception e) { /* ... */ }

May be thrown again from inside a catch block with the statement throw; without needing to specify the instance being thrown (it automatically re-throws the exception instance that had been caught)

When an exception is thrown

The current statement block terminates immediately where it is, and checks if there's a catch block in it's parent blocks scope. 
If no catch is found right away, it "bubbles up" scopes through statement blocks and functions terminating each one exactly where it is, and looking for a catch block which would match it's type or one it derives from. 
If no catch is found all the way up to the main(), then the main() will terminate ending the entire application process. 
If a matching catch is found, the application begins executing at the point of that catch block, and continues on from there. 

A catch block

May specify a type of Exception it catches. 

If it does, that type and any types that inherit from it will be caught in this block if they aren't caught in a lower-scope. 
If it does not, any and all Exceptions that are thrown will be caught in this block. 

May specify a variable name so that the Exception is addressable as a variable when caught as catch(Exception variableName) { /* do stuff with variableName here */ }

Does not have to specify a variable name and may simply catch(SomeExceptionType) { /* the exception is not available here */ }

May throw; without specifying which exception to throw and it will simply throw the exact Exception that was caught.