if we run this simple script using our existing no_return functionwhich as we know very wellalways throws an exceptionwe get this outputi am about to raise an exception caught an exception executed after the exception the no_return function happily informs us that it is about to raise an exceptionbut we fooled it and caught the exception once caughtwe were able to clean up after ourselves (in this caseby outputting that we were handling the situation)and continue on our waywith no interference from that offensive function the remainder of the code in the no_return function still went unexecutedbut the code that called the function was able to recover and continue note the indentation around try and except the try clause wraps any code that might throw an exception the except clause is then back on the same indentation level as the try line any code to handle the exception is indented after the except clause then normal code resumes at the original indentation level the problem with the preceding code is that it will catch any type of exception what if we were writing some code that could raise both typeerror and zerodivisionerrorwe might want to catch the zerodivisionerrorbut let the typeerror propagate to the console can you guess the syntaxhere' rather silly function that does just thatdef funny_division(divider)tryreturn divider except zerodivisionerrorreturn "zero is not good idea!print(funny_division( )print(funny_division( )print(funny_division("hello")the function is tested with print statements that show it behaving as expectedzero is not good idea traceback (most recent call last)file "catch_specific_exception py"line in print(funny_division("hello")file "catch_specific_exception py"line in funny_division return anumber typeerrorunsupported operand type(sfor /'intand 'str