I'm guessing you mean a 'dictionary' of exceptions, with descriptions/implications/resolutions?
This will be very difficult to do retrospectively because the only information is in the logs and queues, which may well have been archived or deleted as part of general housekeeping and DB maintenance.
Most business exceptions should be documented during the requirements/definition/design phases, with maybe a few more revealed during dev and test. Regardless, pretty much all business exceptions should be documented before go-live, with any 'surprise' exceptions appearing after go-live added to the list.
System exceptions are much harder to predict and document, due to the sheer variety and also because you have little control over them. If your target app is 'having a bad day' where wait stages that normally work begin to time out, then defining the cause/effect/resolution will be tricky.
But your instinct to find ways to manage exceptions are correct, and fall into the Service Model category of the BP Robotic Operating Model.
https://portal.blueprism.com/rom/service-model
https://portal.blueprism.com/rom/implementation/service-model
