I think you did not fully grasp the idea behind the handling of interrupt handler names in most Cortex M toolchains.
As you might know, the core uses a table with a list of all interrupt vectors specified for this specific MCU, starting with the reset vector. All offsets into this table are fixed for a specific MCU, with the first dozen (roughly) fixed for all MCUs (defined by ARM).
Since the MCU starts from the reset handler, it was choosen to define the entire vector table, and initial settings for all entries (or some of them). Often default handlers that do nothing but a while (1) loop. Those functions are defined as WEAK, a method that allows the linker to deal with two symbols of the same name. Actual names depend on the toolchain, and might differ from one to another.
And yes, for using a peripheral and it's interrupts, you are supposed to use exactly the name as defined in the startup file / vector table. And not declaring your function as WEAK gives it precedence over the default function. This happens at link time, no need to change the vector (handler address) at runtime using __NVIC_SetVector().
> if you using sdk and included timer files. these file might already have CTIMER0_DriverIRQHandler() defined there, so be aware of declaring CTIMER0_DriverIRQHandler again without removing it from the already existed file.
This SDK interrupt handler is then already part of your (example) application - as if you had written it.
Since the SDK example sources are copied into the project, I use to overwrite such interrupt handlers if they don't fit my purpose. "Overwrite" meaning remove the provided code, and add your own.
Some frameworks (like RTOSes) "seize" most interrupt handlers, and provide callbacks instead.