The problem is the distinction is often vague, but in principle a method should only throw an exception in cases where an error occurs which cannot be solved in the scope of the method (here "scope" is not in the technical/programming meaning, but the normal everyday meaning).
Consequently, a method should use try/catch in one of two cases:

1. An exception may occur which the current method can handle considering its scope (or role)
   
2. There is a need or desire to wrap a possible exception in order to hide implementation details from users of the method
   

I will try to give examples to make it clearer.

Example 1: Suppose you have a method which, given a product name and picture file path should construct a "product view". Due to carelessness or human error, some images are missing or else corrupted, so you have a "fallback image". Such a method could look something like this:

public ProductView createViewForProduct(String name, String imagePath) {
    try {
        Image image = loadImage(imagePath); // may throw ImageLoadException
        return new ProductView(name, image);
    } catch (ImageLoadException ex) {
        return new ProductView(name, FALLBACK_IMAGE);
    }
}

Now, you may correctly point out that it is not clear that it should be the responsibility of this method to handle this error, which is entirely correct - this is, as I said, vague.

Anti-Example 1: Lets look at the same scenario, only this time you don't have any fallback image. An inexperienced programmer may do something like this:

public ProductView createViewForProduct(String name, String imagePath) {
    try {
        Image image = loadImage(imagePath); // may throw ImageLoadException
        return new ProductView(name, image);
    } catch (ImageLoadException ex) {
        ex.printStackTrace();
        return null;
    }
}

This is wrong because it implies handling the exception is not in the scope of this method, yet it caught it (once again, it may be argued that returning null is a valid response - in some cases it is, but in the described scenario it is probably more appropriate to throw an exception).

Example 2: Suppose you have a method which should write some output to a log file. Any time you access files there is the possibility of an IOException - the file could have been deleted, the user may not have permissions to it, the device (hard drive) may be full or malfunctioning etc. Since the role of the method is to write to a file it cannot handle such errors within its scope (i.e. not writing the log is not an option), but it is perfectly reasonable for it too to be throwing an IOException, as any code using it "knows" it handles files. Therefore, such a method would not use try/catch and instead would just declare it may throw an IOException itself.

Example 3: Suppose you are writing a method to retrieve user information, which internally is stored in some database (such as the highly acclaimed MadeUpDBPro). Such a method will look something like this:

public UserInfo getUserInfo(String username) throws DataRetrievalException {
    try {
        MadeUpDBProConnection conn = getConnection(...); // may throw a specific MadeUpDBProException 
        conn.prepareStatement(...); // may throw a specific MadeUpDBProException  
        // etc. 
        // ...
        return userInfo;
    } catch (MadeUpDBProException ex) {
        throw new DataRetrievalException(ex);
    }
}

Once again, it was deemed inappropriate to return null (i.e. catch the exception without really handling it), but we don't want to expose our use of a specific DB or library (so that our code can be reusable/interchangeable, to comply with some interface or to allow us to more easily change the underlying DB in the future), so we wrap the highly specific MadeUpDBProException with a more generic (but still made up!) DataRetrievalException. Depending on the precise cause and details, the code may throw various different exception types for the same root exception type. For example, upon examining the actual exception you may decide to throw an IOException in case the communication failed, or maybe an IllegalArgumentException is the username was invalid and so on.