2

I'm working on a large scale software system written in Python right now, which includes multiple modules. I was wondering what I should do about this, if anyone could make any sense of this error message that I keep receiving:

  File "<string>", line 1, in <module>
NameError: name 'CerealObject' is not defined

The thing that makes it very cryptic is that it seems to not provide an actual file name or a specific module. From a beginner's standpoint this makes it seem impossible to debug.

Jacob Griffin
  • 4,807
  • 3
  • 16
  • 11
  • 1
    Did you grep for `CerealObject` and find lots of instances? That `line 1, in ` stuff usually happens from the REPL. – nmichaels Jan 03 '12 at 18:47
  • It's not that ambiguous, it cannot find 'CerealObject' are you importing it correctly? import CeralObject from ... – Kekoa Jan 03 '12 at 18:47
  • @nmichaels - Well, the thing is, this error *never* occurred in the past, it appeared when I added a new module that doesn't have anything to do with calling CerealObject – Jacob Griffin Jan 03 '12 at 18:48
  • Can you post some code so we can see better? – Kekoa Jan 03 '12 at 18:49
  • I'm not sure which code (file) to post.... that's part of the problem – Jacob Griffin Jan 03 '12 at 18:49
  • @Kekoa - It seems that this error started occurring only after I added in a new module that doesn't even have any relation to the referred object. This makes it confusing since I'm not sure which of the original modules I had needs to be fixed.... logically since I didn't touch any of them before and it worked fine, it *should* be working now as well. – Jacob Griffin Jan 03 '12 at 19:13
  • So unfortunately, I'm not sure if importing is the problem. – Jacob Griffin Jan 03 '12 at 19:14

1 Answers1

2

File "<string>" in an exception stack trace typically means that you're using either exec or eval somewhere. They execute code from a string, hence the lack of an actual file name.

You'll need to look at the following line(s) of your stack trace to determine the source of the problem.

Laurence Gonsalves
  • 137,896
  • 35
  • 246
  • 299
  • Normally the stack trace (also called a "traceback") is dumped to stderr, but it's possible that it's being sent somewhere else (like a log) or perhaps even swallowed up by your program. The error message you posted in your question comes from the beginning of the traceback, so where are you seeing it? – Laurence Gonsalves Jan 03 '12 at 19:08
  • It's basically in the log output of my program. I now understand what you mean by stack trace (In the output of my program, they refer to it as Traceback). – Jacob Griffin Jan 03 '12 at 19:10
  • Normally, my log prints multiple places where the particular error was caught in the Traceback sequence, but this time all it does is print the one generic error message I posted in the original question, and nothing additional – Jacob Griffin Jan 03 '12 at 19:11
  • Sorry for the confusion. "Traceback" is the normal Python terminology, but I'm more used to the term "stack trace". – Laurence Gonsalves Jan 03 '12 at 19:14
  • @JacobGriffin Does it normally include a message like "Traceback (most recent call last)" in the log, and if so is the place with this NameError missing that line? If so, then I _suspect_ that what may be happening here is that some place in your program is catching the exception and just logging the exception's message without the traceback. – Laurence Gonsalves Jan 03 '12 at 19:19
  • @JacobGriffin The best thing to try, if possible, is to run the code in a (Python) debugger. Another possibility would be to search the code for calls to `exec` and/or `eval` and see if they do anything suspicious with exceptions. Yet another idea might be to instrument your logging framework to tell you the line of code that called into the logging routines. – Laurence Gonsalves Jan 03 '12 at 19:22
  • So it does print "Traceback (most recent call last)" as always, and the eval method I think is being called in C++. This might be a bigger problem than I thought... – Jacob Griffin Jan 03 '12 at 19:58
  • @JacobGriffin In that case GDB (or some other native debugger) probably is the right tool for the job. – Laurence Gonsalves Jan 03 '12 at 21:46