IssueTracker

Component used: Room
Version used: Room 2.0.0-alpha05
Devices/Android versions reproduced on: Any

Recent deprecations influence business logic flow a lot. Example: remote server's response parsing (I think, rather common case).

Old way:

// JSONException is thrown upper, so it can be managed alltogether with HTTP response errors (for example, just ignored to use old data on unexpected response format)
public void parseResponse(final JSONObject obj, final JSONArray subObjs) throws JSONException
{
    db.beginTransaction();
    try {
        final DBItem item = db.getDaoItem().findItem(obj.getLong("id"));
        item.parseSomehow(obj);  // throws JSONException on failure

        final DBSubItem[] subitems = db.getDaoSubItem().findSubItems(item.getId());
        db.getDaoSubItem().replaceSubItems(item.getId(), DBSubItem.parseSomehow(subObjs)); // replaces, reusing subitems with updating inner order; throws JSONException on failure

         db.setTransactionSuccessful();
    } finally {
         db.endTransaction();
    }
}


New way (looks worse, no exception type control - so you can throw anything and check it only in runtime):

public void parseResponse(final JSONObject obj, final JSONArray subObjs) throws JSONException
{
    try {
        db.runInTransaction(() -> {
            ... // same code as in previous example inside try...catch
            return null;
        });
    } catch (RuntimeException e) {
        if (e.getCause() instanceof JSONException) {
            throw (JSONException)e.getCause();
        } else {
            throw e;
        }
    }
}


Of course, I can try to separate parsing from database interaction, but it would require at least temporary objects with no more usage (in the project's code). Additionally, sometimes next parsing steps depend on previous / storage data.

Final thoughts. Looks like runInTransaction should be recommended method in most situations, but the old way is still convenient too.