The scenario simply cannot occur unless someone modified the database manually. Drone won't start anyway, so I could've left out the else entirely.
But it feels cleaner to throw so we know there is something in there that we don't know how to deal with, that way drone rejects the migration and dies instead of doing a migration to a version that doesn't even know FolderSettings used to exist.
Yes, you could just remove the junk but that's not the job of a migration. The job of this migration is to convert any download client with FolderSettings to their new variants, if that job fails, throw.