Is wrapping exceptions good practice? I have recently been refactoring some code in an effort to improve the exception handling, particularly to aid in improving the level of information given to developers during development. However I am worried that I have started down the wrong path.
For example we were getting complaints that the following code threw an exception with the message: Sequence contains no elements when a database does not contain a record with the supplied ID.
public Record GetRecord(string id)
{
    _dbContext.Records.First(r =&gt; r.Id == id);
}

After refactoring the code, it now throws an exception whose message is No record found with id: {0}.
public Record GetRecord(string id)
{
    try
    {
        _dbContext.Records.First(r =&gt; r.Id == id);
    }
    catch(InvalidOperationException ex)
    {
        throw new ApplicationException(string.Format(&quot;No record found with id: {0}&quot;. id), ex);
    }
}

I can understand that this error message might be clearer, as we now know that no record was found. However, using this logic, where should we stop? Surely the below would also be an 'improvement'
public Record GetRecord(string id)
{
    try
    {
        _dbContext.Records.First(r =&gt; r.Id == id);
    }
    catch(InvalidOperationException ex)
    {
        throw new ApplicationException(string.Format(&quot;No record found with id: {0}&quot;. 
    }
    catch(SqlException ex)
    {
        throw new ApplicationException(&quot;An error occurred while processing the record&quot;), ex);
    }
}

I would consider it bad practice to wrap exceptions like this, however I am willing to be proved wrong. Is there any reason why this would be desirable? Where should the line be drawn?
Microsoft provide the following advice

Consider wrapping specific exceptions thrown from a lower layer in a more appropriate exception, if the lower layer exception does not make sense in the context of the higher-layer operation.
This should be done rarely because it makes debugging more difficult. It is appropriate when you are certain that the lower layer is never the true source of the error.

However surely an exception can also be wrapped in a more appropriate exception?
There is little reason to do this. If you include the stacktrace in your logs you already know where the problem exists; the only thing you'd miss is the input which you might know from different channels (and often isn't necessary to figure out the problem).

Noting that your example returns void which is probably not what you intended, I should say that the change I would make is to use .FirstOrDefault() instead of First which will instead return the default value - null for a reference type. You can then work with a simple null check to see whether or not a record was returned instead of having to start using try-catches. 

Yes, you could do all this to provide specific error messages. Personally I am not a fan of it and I prefer to derive this from the code itself (through for example the before-mentioned null check).