Ah dear!
You have practically screamed at us that you have not the slightest idea of the purpose of an interrupt!
Yes, it is a "newbie" trap to be sure.
Someone who is not experienced with computing sees the word "interrupt" and thinks "Ah, I can use this to interrupt one process and make it do something different". This is simply not the case. The whole concept of an interrupt is that a critical operation which it is necessary to perform with a very small delay of an event occurring and which can be dealt with - not necessarily completely, but the necessary action can be initiated and allowed to proceed - very quickly, can be performed without significantly affecting or altering the operation of the main program stream in any way apart from a negligible delay.
{As an extension of this, multiprocessing operating systems may - using interrupts for "pre-emptive multi-tasking" - allow a number of program streams to proceed independently such that each program "sees" itself as the only one running, but cannot rely on how fast it will run.}
Having a program - "sketch" - alter its action in response to an event which "interrupts" its "train of thought" is on the other hand, entirely the responsibility of that program or process. There must be some point in that process where it makes a decision on which path to follow and if it is to be promptly responsive to an event such as an input from a switch, optical encoder, serial port or similar, then it must return to check for such an event frequently, which process is called "polling".
Only if the event which is to affect the program flow is so evanescent that it may have gone away by the time the main process loops through to poll it, will it be appropriate for the event to trigger an interrupt which does nothing else but set a marker variable - a "flag" which the main process can read in due course, and then clear the interrupt and return to the main process. A manually operated switch or encoder is almost never going to constitute such a situation.
Now in your case, two things are relevant. One is that your safety barrier switch must by definition simply cut off the power to the equipment. Not via the Arduino, because if the Arduino program "crashes" - as it just might - then the system will continue merrily on under no control at all.
That understood, what you have not taken into account, is when your proposed interrupt occurs and you shut down your mill, what the program does next? If you have indeed interrupted the process at a random point and taken certain actions, then you have lost the current status of the procedure, you cannot just exit the interrupt and imagine things are going to proceed as before. What did you intend to do?
No, it is all a matter of planning. Your "linear" code must proceed in defined steps (using "state machine" coding to work through the steps) where each step (and with a very fine resolution) is dependent on polling your safety switch, allowing it to shut down in an orderly fashion and re-start. The shut-down itself is an alternate process in the sequence of operations and handled as such in your "mainline" code.
You can not (certainly should not) "patch" improperly organised code by inserting random "exceptions" as interrupts.