Macro's can be a great help in making your coding more readable and I'm very much in favor of using them. Their use should be warranted, by the repetitive nature of the logic you want to capture in the macro. Defining a macro with DEFINE my_macro. and END-OF-DEFINITION. is in fact an abap editor prepration step. When the abap program is executed, macro's are resolved and the coding that is eventually executed no longer contains macro's. Thus a macro is not a languange element, it is an editing/editor feature.
This also implies that the coding you are composing is re-arranged (macro logic is untangled) before it is compiled. Fine for us humans, as we never get to see the untangled version of our "macro-lidified" coding, however the debugger likes to have every bit of coding available - so it can show us exactly what line something went wrong. Result ? A macro can not be debugged. Solution ? When your in the development phase - simply place the coding logic from your macro, outside the macro. With small adjustments the coding should work and the debugger is granted access to debugging. After the problem is tackled, resolve and place your coding back into the macro form. By example:
DEFINE my_macro. &1 = &2 / &3. END-OF-DEFINITION. my_macro: v1 v2 v3.
If v3 is 0, the program will dump and the debugger won't be able to locate the error very accurately. Allow the debugger to work by executing the logic from the macro directly (so debug the coding from the macro, without the macro). Is the macro you are debugging already live ? There is not much you can do then.. A very good reason to keep macro logic short, sweet and simple.