php - Is it good practice to always catch an exception in the higher-level object? -

as project gets bigger , bigger, bit confused types of exceptions should thrown , should caught, e.g. how organize internal exceptions vs exception messages should shown end user. keep confusion down, best practice catch exception in higher-level object?

take example: if have database class inserts row database, , class called object processes data, , in turn data processing object called controller, correct catch errors database class in processing class, (possibly) rethrows error caught in controller class? or can error thrown in database class caught in controller class?

additionally, if 1 method in processing class called method in same class, , first throws error, ok catch exception in same class? or should deferred higher-level class that's calling it?

are there other tips on how structure , organize exceptions in large projects many levels of classes?

1. an exception should thrown in exceptional event, i.e. if wrong , code cannot continue is. e.g. database down, remote service not responding, malformed input received.
2. if catch exception, need know it. when exception has been raised, means application in serious error state. if catch exception, should have serious plan on how proceed error state. if don't have plan, there's no point in catching it. if database down, want stop program. on other hand, if remote http request yielded 404 response , http handler throwing exception, able live error , continue (depending on request supposed used for).
3. raw exception messages should never shown endusers. exception needs logged, enduser should see generic nice "oops, went wrong, maybe want try x instead...?" message. not specific exceptions, it's ux design.