Strangely, I read "unfamiliar source code" as "hostile source code". Because it often is.

You'll sometimes even wonder if the coder has volontarily overcomplicated everything (e.g. sliced a simple flow in multiple callback-ridden subprocesses) just to screw with you.

But more seriously, I do not know a simple method to read hostile code. I work in a SaaS-architectured IS, so my experience may not be applicable to your current problem, but what I do is :

1. Look for external API implementations and isolate them. Those are the limbs of your code. They are here to augment the data processed by reading a database / a file, calling a service / an engine... Sometimes the data they return may alter the flow, but the implementation of these interfaces are really dumb : map from one type to another, call a low-level API... You don't need to dive in them early (except if the code you have to extend is there, but in this case this should be piece of cake).
2. Look for business classes. Those are the trunk of your code. They control the workflow, make the decisions and generate functional errors. If business classes are implementation of business interfaces, that may imply some sort of business-level framework, which may simplify your work.
3. If there are no interfaces, you may be screwed : you are facing something written like a script, monolithic and virtually non evolutive. Sorry.
4. Look for the authors. Who knows, they're maybe still around, and perhaps willing to help
5. In general, if you want to be more efficient in this task in the future, keep yourself updated about design patterns and frameworks. There is nothing scarier than having to decypher a pattern you never heard about (looking at you, RoR "artisans")...

All in all, welcome to hell.

I'd replace the

catch (Exception e) {

by a

catch (Throwable th) {

Because, who cares about errors ?