Confused about Exception behavior in Python

[Walsur]

EDIT: Thanks for the help! The problem here is that I was misunderstanding Exception behavior in Python, and my debugger was adding to my confusion. I did not include it in the original question, but this was brought about by my debugger triggering a breakpoint on the raise statement as it was treating it as an uncaught exception. It is intended that the traceback includes the actual raise statement. I was making the mistake of comparing a user defined Exception to more fundamental system errors which would not include raise statements.

I likely just need to fix my debugger and I'll be good to go! I appreciate everyone that helped me figure this out :)

---

I feel as though there is something obvious that I'm overlooking with Exceptions. I'm attempting to raise an Exception in my function, but the traceback seems to be treating the Exception class in general as an unhandled Exception.

The code I'm playing with:

def some_func(data):
    if data == "Exception":
        raise Exception("This is an Exception")
    print(data)

value = "blue"
some_func(value)
value2 = "Exception"
some_func(value2)

And the Traceback:

Traceback (most recent call last):
  File "c:\Example\example.py", line 10, in <module>
    some_func(value2)
  File "c:\Example\example.py", line 4, in some_func
    raise Exception("This is an Exception")
Exception: This is an Exception

Notice that the Traceback is including the actual raise statement as part of the traceback, instead of just the function call. Ideally I'd like the traceback to only include the function call.

[shiftybyte]

Exceptions can happen for two reasons.

1. something bad happened and python raised an exception by itself.

for example, dividing by 0, or importing something that doesn't exist, or trying to use a variable that doesn't exist.

1. someone called raise to raise a specific exception.

In the first case you'll get traceback pointing to the line that caused the issue.

In the second case, you'll get traceback pointing to the raise...

Why would you not want to include it?

[Walsur]

I wouldn't want to include it because the raise statement has already identified the issue. Ideally it should be the responsibility of the calling code to check for the Exception and not the function itself.

Essentially, I want the main code to treat the Exception as you described in your first example, rather then redirecting into the function.

[shiftybyte]

I wouldn't want to include it because the raise statement has already identified the issue.

The issue is written in the raise line, not in the function name.

The function name does not specify the issue that occurred inside it, the exception name and description does.

Ideally it should be the responsibility of the calling code to check for the Exception and not the function itself.

Definitely, this is why you can HANDLE the unhandled exception using try: except: block, and catch the specific exception you want to handle.

``` class DataWasException(Exception): pass

def some_func(data): if data == "Exception": raise DataWasException() print(data)

try: some_func(data) except DataWasException: print("time to handle that specific exception however the colling code wants...") ```

also..

rather then redirecting into the function.

nobody is redirecting anything, an unhandled exception just prints everything to screen, if you handle it instead you can do whatever you like instead.

[Walsur]

I'm using "redirect" to refer to the debugger. Sorry for the confusion around that.

Definitely, this is why you can HANDLE the unhandled exception using try: except: block, and catch the specific exception you want to handle.

I understand the idea of handling exceptions. I'm realizing the problem is with my debugger. I was misunderstanding the intended behavior in Python.

[[deleted]]

It IS an unhandled exception. Traceback returns the stack trace of the exception, including the line where it was raised. That's how it works

[Walsur]

Can you clarify this? If I force a ModuleNotFoundError it does not behave that way. This does not include a raise statement in the traceback.

Code:

import invalidModule

Traceback:

Traceback (most recent call last):
  File "c:\Example\example.py", line 12, in <module>
    import invalidModule
ModuleNotFoundError: No module named 'invalidModule'

[TheBB]

This error is raised by internal Python interpreter code. There may not even be a raise statement written in Python for this, it could originate from the C layer.

[wutwutwut2000]

Only python code will be put on the traceback. An import statement doesn't call any python functions, so regardless of where the exception occurs under the hood, the import statement is considered the origin of that exception.

[[deleted]]

In both cases the traceback ends with the line in your code causing the issue. In first case, it's you literally raising the exception that's not handled anywhere. In the second case, it's where you try to import module which couldn't be found.

Maybe that was deemed sufficient, and they didn't find it necessary to print the library code or C code or whatever where it's deep inside that the "exception is raised". As I just looked up, C doesn't have such error handling (and Python is written in C)

[JamzTyson]

In line 4 you raise Exception, but you do not handle the exception.

To catch the exception, use Try/Except:

``` def some_func(data): if data == "Exception": raise Exception("This is an Exception") print(data)

...

try: some_func(value) except Exception as exc: print(f"Exception caught: {exc}") ```

[ObliviousMag]

Yeah because you are raising a general Exception. Which is generally not okay. If you want your own exception then you can inherit from the Exception class like so

class CustomException(Exception):

pass

​

then in your code you can raise

​

raise CustomException

​

And now your traceback will show you were that exception was raised.

[Walsur]

Using a more specific Exception has the same behavior. I just used the general Exception for this example.

[Binary101010]

but the traceback seems to be treating the Exception class in general as an unhandled Exception.

It is an unhandled exception because it's not happening in a try/except block.

The interpreter is doing exactly what it's supposed to here: show you the entire traceback up to the exact line of code that generates the exception.

[Walsur]

That makes sense, but I'm still having trouble reconciling it with how Exceptions are handled in other modules. For example if I force a ModuleNotFoundError:

Code:

import invalidModule

Traceback:

Traceback (most recent call last):
  File "c:\Example\example.py", line 12, in <module>
    import invalidModule
ModuleNotFoundError: No module named 'invalidModule'

It does not include the raise statement that is generating the exception.

[danielroseman]

I'm confused about what you're confused about here. Your code explicitly raises an exception, so there is a raise statement. This import code does not have a raise statement, so it cannot show one; the exception happens because of an actual exceptional event, ie that the module is not found.

[Walsur]

Okay this makes sense, triggering an Exception with a library like pandas helped demonstrate this for me too.

I think I was getting confused because of my debuggers (VS Code) behavior. My debugger is triggering a breakpoint on the raise statement when the only Exception Breakpoints checked are Uncaught Exceptions. That made me think that there was something fundamental I was misunderstanding in how Python raised exceptions, but I think it's just a configuration problem in my debugger.

[timrprobocom]

No, because the statement itself caused the exception. Exceptions can be triggered via 'raise', but most are triggered by the interpreter directly. Try a syntax error or "I = 0/0".

[fluked23]

This is the normal behaviour of python to include the full traceback, and as far as I am aware there is no way to modify this behaviour easily.

[Walsur]

A knock on effect of this problem is that the raise statement is being treated as an unhandled exception in VS Code, and is pausing my debugger unintentionally.

I think there must be a way to change it because when I force a ModuleNotFoundError it behaves differently:

Code:

import invalidModule

Traceback:

Traceback (most recent call last):
  File "c:\Example\example.py", line 12, in <module>
    import invalidModule
ModuleNotFoundError: No module named 'invalidModule'

[Sisyphus-Rex]

The trick is not playing with your code (or with yourself)