Error Handling in General

I am thinking about this topic for 4 months+ now. I know different languages and different approaches the 3 mentioned are just the most obvious ones and can be combined.

To me the question about error handling is about information, to the maintaining person you want to have meaningful information "how/why/where/what" they have to be granular.

For the GUI you need meaningful information but only the essential information "x y z could be done or not ... please do ..."

So the thing is, The exception model has its merits you can easily build a strict contractual model for the Errors

methodX(always-in): always-out

This is cool for side-effects like database access or file reads and you can remove a lot of "if else" cases that basically bloat your code by just placing them in a catch statement.

But than you still need to pass meaningful information to the GUI which can be an error code or you catch the "systemException" and "re-throw a Meaningful" one.

But as soon as you go for batch processing this model suddenly can become a lot of overhead. An ErrorObject (like go) approach can be much more meaningful and less resource costly since having 30 times the same error with just a different parameter is TMI as well as useless computation. But sadly not every language support two return parameters. Hence in a classic OOP architecture you will have a error Queue or you use the signature-contract-precision (in a dynamic language).

So anyhow .... I did think about 5 different core approaches and their trade-offs and their combinations.

Maybe someone could add something meaningful to my process, I would appreciate it.

Important to me is the reasoning! Why you chose that way and how you handle the gap between "essential for the user" vs "essential for the maintainer".