A script wraps an API call in a handler that catches every exception and then prints that the change succeeded. The API rejected the change. The script prints success. What hid the rejection?
Select an answer to reveal the explanation.
Short Explanation
The API said no, and your script threw that answer away and printed yes. The handler is what hid the rejection. A WLAN name does not force a success message.
Full Explanation
An exception handler that catches every failure and then prints success will report success when the API rejected the change. The handler hid the rejection. The API did not return success and rejection as the same status. The rejection happened, and the script chose not to show it. A WLAN name does not force that print. The channel is not something the handler must read before it is allowed to report a failure. The report is whatever the script prints after it swallows the error. The script catches every exception and then prints that the change succeeded. The failure is hidden. The handler is the bug. Check one live client after the change and leave the rest of the floor alone until that client matches the result you expected. Read the live counters after you retest. Exam caveat: catching a specific, expected error and logging it is reasonable. Catching everything and claiming success is how a bad change ships. Operational check: remove the blanket success print, run the rejected call again, and confirm the script shows the failure.