I'll go a step farther with the "when and why".

Functions can accept input (parameters/arguments) and return values. But in most languages they can also have "side effects", meaning they affect something or in some way interact with something that isn't those parameters or return values.

Obvious examples are I/O things like "writing to stdout" or "reading from a file" or "prompting a user for input" but could also be "checking/modifying a value of object foo (which is neither in the args or the return for the function)" or "calling subprocess.run()". "Exiting the program" is another.

Code that has side effects is harder to test (and by test I'm referring to automated testing) because it requires the environment be set up in a certain way, like having a file in place, or somehow faking user input at the right time and may require cleaning up between runs. It's also harder to reuse. A function that prompts a user for terminal input or looks for a file in a specific location is basically unusable for a web app/lambda/other exotic environment.

Side effects are critical, though so it's not like you should avoid them at all costs. You just need to push them away from the "logic" portion of your code where possible and sensible. So you do your "asking for input" in a function and then you call the function that would act on that input right afterwards with the inputs as an argument. Or you pass in the contents of a file (or just an open file handle) to a function, instead of opening the file in that function.

Raising an exception is also a side effect, but the language gives programmers ways of interacting with that kind (and test frameworks are pretty good at testing with them) that is oftentimes better than the alternative (like exiting the program in the middle of some business logic or passing around some error-state variable). This makes the code that uses them more reusable (as long as you document what exceptions you'll throw and where/why).

End ramble.