Bubbling exceptions up from sub packages

Question

Hi.  We run 2012 std.  We r trying 2 get our heads around the options we would have customizing capture of exceptions that bubble up (if that is possible) to our master pkg from sub pkgs.  This question is independent of ssis's sys logging.
My recollection is that ssis tells us a lot (maybe too much repetition) about exceptions.  Our goal is to customize how we deal with exceptions at lower levels in the master pkg itself (perhaps in the .net service that calls the mstr if that can be
bubbled up) so that we aren't incorporating the same custom logging at every level of the ssis call "tree/structure".
We capture some exceptions already in vars by incorporating try catch blocks in our c# scripts.  But haven't addressed yet how those might be bubbled up.  It is hoped that whatever we do with these can mimic what we do with exceptions thrown by
other ssis components where there is no c# code to catch the exception.
Can the community get us started?

Answer 1

this is what I'm concluding from what I see and what the community has said thus far:
If our goal is a tool that can answer most inquiries about what our etl has done,
1)   forget about dbo.sysssislogs .  It doesn't record exceptions.  Traceability may be present but at what cost?  It is susceptible to different approaches used by different programmers working on different pkgs.  Its
not a question of if but rather when it will be truncated and thus be out of sync with supporting custom log tables.  It is probably going to behave differently from release to release of ssiis.
2)  keep that flat file ssis log around.  I'm not sure what its formal name is but we often append a datestamp to a file name we give it when running pkgs from the command line.  As much of a challenge as it is to read that
file, it seems more informative and friendly to me than dbo.sysssislog.  And kills two birds with one stone in the event that custom logging cant make a connection to the db where custom logging takes place.
3)   get serious about ssis component naming conventions.   How informative is "For Each Loop" when trying to make heads or tails of what a log is trying to tell you.
4)  don't allow parallel processing (neither in cf not df) until ssis gets better at the whole var locking unlocking race condition thing.  Handle locking yourself.  Incorporate multiple pkgs if both parallel processing and
useful logging r important.
5)  bake record counts, start times and end times into your logging solution.  Reject counts as well if applicable.         
6) use pre, post and error handlers to do the logging with a std toolbox item if possible thus leaving pkgs more readable.  Record parent child component traceability info that is exposed in these handlers thru system vars.  Supplement latter with exceptions
caught in c# scripts.  Use views and indexes for the dashboards that will need to look at this stuff from different perspectives and permissions after the fact.  Prepare for repetition where errors bubbled up thru parent ssis components.
7)  get an answer on guids when ssis components r copied from place to place.  If a new guid isn't created, find a way (I think there is a tool for this), to generate a new guid for the new component.  I think a component guid column
would be germane to a custom logging tool.  Similarly watch out for changing a component's guid once logging has begun.