Your problems seem to be caused by your attempt to mix different error handling paradigms.
If you used exceptions only, bar() would not return a bool, but either succeed or throw. Same for outsideResource(). With that approach, bar() would just call outsideResource(), maybe do some logging and be done with it.
Or you could avoid exceptions, instead return bools or objects/None, in which case you get one simple function calling outsideResource(), then branching on the result and either logging success and returning true, or logging a failure and returning false.
Either implementation is concise and not an anti-pattern. Your long-windedness stems from the fact that you're switching between the paradigms - or even using both in a single function (like outsideResource).
My advice is to stick to one paradigm inside your core application; preferably the same paradigm that your standard library uses. (I personally like exceptions, but YMMV.) That keeps the amount of wrapper code minimal. Sometimes you have to wrap external libraries, but that can be handled.
If you must wrap methods this way, it probably won't get much shorter than your example. You could make a helper function that takes something callable, executes it, catches exceptions, logs everything, then either returns true or false, so your code reduces to
However, as soon as you want to get situation specific logging text in there, or different logging priorities, or any other customization, that brevity is gone again.