Centralizing the code is usually always a good idea. We must re-use the code as much as possible.
However, it is important to note how to do that. For example, when you have a code that does compute_prime_number() or check_if_packet_is_bad() it is good. Chances are that the algorithm of functionality itself will evolve that will be benefited.
However, any piece of code which repeats as a prose doesn't qualify to get centralized right away. This is bad. You may hide arbitrary lines of code inside a function just to hide a code, over time, when multiple parts of the application begins to use, they all must remain compatible to the needs of all callee of the function.
Here are some questions you should ask before asking
Has the function you are creating its own inherent meaning or is it just a bunch of lines?
Which other context will require the use of the same functions? Is it likely that you may require slightly generalize the API before using this?
What will be the expectation of (different parts of the) applications when you throw exceptions?
What are the scenarios to see that functions are going to evolve?
You should also check whether there already exists stuff like this. I have seen so many people always tending to redefine their macros MIN, MAX rather than searching for what already exists.
Essentially, the question is, "Is this new function really worthy of re-use or is this just a copy-paste?" If it is first, it is good to go.