http://nedbatchelder.com/text/exceptions-vs-status.html

There's also gprof2dot as an alternative to kcachegrind that gives you its main functionality (pretty tree graphs of where all your page load time is coming from).

I thought it made sense to just extend the PortageTree class on PortageCategory

You might want to recheck the Object Oriented Design rules. A Category is-not-a Tree, unless you are trying to say that a Category is interchangeable with the root node of the portage tree which I didn't think was the case. You're looking for Composition, a Category has-a owning tree, but it is not actually a tree itself. The singleton approach is good enough, though if you want to include overlays (sunrise?) in it then you may want to allow multiple PortageTree instances for each overlay.

The main OOD/OOP class design rules I remember are:
Classes represent things. A File, a Person, a Button.
A class must do one thing, and only one thing. All functions should be aligned towards one purpose (The rule of cohesion). eg. A Database class should only operate on the contents of a database, it should not include public functions to open or delete files, network connections, calculate taxes, etc.
A class can be a more specific type of something else (Inheritance, the is-a relationship). For example, an IceCreamTruck is-a Truck is-a Vehicle.
A class can be made from "parts", that is, member variables which reference other objects (Composition, the has-a relationship). Example: A Truck has-a Wheel, but it is not a Wheel itself.

You need to be careful that you don't try to use inheritance as a shortcut, even if that means rewriting similar code, as you'll usually just end up making the code more tightly coupled (inter-dependent) and that makes it harder to fix or improve later on.

---
For exceptions, the jury is still out on that. Usual arguments are that exceptions make code visually leaner since you don't have to use lots of "if (errCode != 0) return errCode;" things, however, the "try/catch" structure is often more ugly. Some people claim that it stops the error recovery from obscuring the normal behaviour when reading code but others claim that it makes it too easy to ignore error cases, allowing them to propagate and cause a crash [the same is said of forgotten error code tests though]. It can also enable you to use multiple functions that may fail in a single statement without intermediate variables and error testing and give a minor performance benefit in some cases. Generally, the best you can do is use the convention of the language; if the language doesn't have much of a convention then just use the same style that everyone else is using on the project; if it's your own project then you can do it whichever way you want. Most of it is just opinion.

Bjarne Stroustrup also has a book out similar in scope by using C++. I haven't purchased it yet, but it probably goes into more depth albeit more dense and difficult due to C++.

I recall trying to explain this to someone at work a while back. The analogy I used was that a person driving a car into a wall would be a normal error code, but a unicorn driving a car at all would be an exception.

I've been on both sides of the fence with this. Lately, especially since having learned more Python, I find that it is really up to the language and culture around it to decide what an exception is used for. For Python, it seems Pythonic to attempt an operation first, whilst catching exceptions, rather than to lay down a number of state checks before attempting an operation, for example.

2¢