How to get the error line?

Python Help
1

I want to ask in general when I execute small code from the terminal I get the error but I dont know which line cause this error so how I know which line ?

Thanks

2

Read the traceback. That will tell you where it detected the error.

The cause might be on that line or on an earlier line that it executed, but you just have to read the code leading up where it detected the error and think about what itā€™s doing to find the actual cause.

3

I dont see any traceback

4

Can you post the code you are trying to run? And the output you are seeing?

5

I cant post the code but the error I get

Error: ā€˜TSK_FS_INFOā€™ object has no attribute ā€˜metaā€™

Thats it no additional output. I am looking to learn in general how to know the cuased line

6

Normally there is a full traceback that shows the line. E.g. given this small script:

a = 10
b = 20
1/0
c = 30

the result from running in the terminal is:

bk333-py312 āÆ python foo.py
Traceback (most recent call last):
  File "/Users/bryan/tmp/foo.py", line 3, in <module>
    1/0
    ~^~
ZeroDivisionError: division by zero

which shows the error was on line 3.

If you are not seeing a traceback then something is different about your code or your setup and we canā€™t help without more details and information.

1 Like
7

Is something in the code catching the exception, printing a message, and then quitting the program? Thatā€™s not helpful for debugging!

1 Like
8

yes this was the reason there is try ā€¦ except block that print the error message. Thanks for this info I am still new to python

Is there a way to print caused line number inside except block ?

9

You could try adding:

import traceback
traceback.print_exc()

in the handler to print out the traceback.

2 Likes
10

Just donā€™t catch the exception. The very easiest way to print out errors, complete with tracebacks, is to do nothing at all.

5 Likes
11

This is a good example of why itā€™s generally (frequently? sometimes? always?) a bad idea to catch exceptions within modules meant to be called by other peopleā€™s code. Unless the module code is going to re-raise it as a module-specific exception or knows itā€™s innocuous and safe to discard, itā€™s generally better to let the calling code handle it.

2 Likes
12

Others have mentioned how you can print the current traceback, and thus
get line numbers, and that often the best thing to do is to not catch
the exception at all (which gets you a traceback when the exception
escapes all the way out).

You may be thinking: ā€œI need to catch expections otherwise my program
failsā€.

The rough rule of thumb with exceptions is to catch them only when you
know what to do with them i.e. you know how to fix this particular
situation.

Hereā€™s an example from my own code. Itā€™s a bit dated (we tend to use
PermissionError these days) but it shows the pattern:

 try:
   dst_taggedpath.save()
 except OSError as e:
   if e.errno == errno.EACCES:
     warning("save tags: %s", e)
     dst_taggedpath.modified = old_modified
   else:
     raise

Here Iā€™m wanting to detect that I donā€™t have permission to save to a
particular file and when exactly that happens issue a warning message
and carry on. Otherwise I want to not catch the exception because it
is a different siutation and I do not have a plan for what to do with
it.

So whatā€™s salient in the above code?

 except OSError as e:

This catches just the OSError class of exceptions. I donā€™t have a plan
for any others, so Iā€™m not going to catch any of those at all.

   if e.errno == errno.EACCES:

Hereā€™s the particular flavour of OSError I understand: permission
denied. For this particular code, thatā€™s ok, so Iā€™m going to issue a
warning message which includes mention of the exception, and carry on.

   else:
     raise

And herā€™es the flip side: it isnā€™t the special circumstance I
understand and handle, so the raise statement reraises the exception,
letting it out.

The core idea here is that exceptions are just that: exceptional
circumstances which we do not expect to happen. You want them to get
out so that they can be debugged and the larger situation fixed. Maybe
the thing calling your code has done it wrong, maybe youā€™re running your
code against the wrong data file, etc etc. All of these are things which
are not your problems: the person/code calling your code has done so
incorrectly.

Donā€™t catch (and thus hide) exceptions youā€™re not specificly
expecting!

Cheers,
Cameron Simpson cs@cskk.id.au

2 Likes
13

The novice thinks itā€™s his job to stop the program from crashing. The expert knows that itā€™s his job to stop the Eagle from crashing. If you want to see what itā€™s like when you DONā€™T have really handy tracebacks, and peopleā€™s lives are on the line, look up the Apollo Guidance Computer and what happened during the Apollo 11 landing - they were getting information from their computer in the form of four-digit message codes.

2 Likes