| 1 |
On Friday 23 December 2005 08:46, Zac Medico wrote: |
| 2 |
> Jason Stubbs wrote: |
| 3 |
> > On Thursday 22 December 2005 16:21, Brian Harring wrote: |
| 4 |
> >>Not sure if hiding the exception away (traceback) is a good thing; |
| 5 |
> >>wrapping it with purdy output, sure, but swallowing it? |
| 6 |
> > |
| 7 |
> > If it's failing to import, there's something pretty wrong with it. I'm |
| 8 |
> > sure that module authors will know enough to remove the except block. Is |
| 9 |
> > there really anything useful gained from dumping the traceback? |
| 10 |
> |
| 11 |
> A while back we had someone in #gentoo-portage with a problem where portage |
| 12 |
> was swallowing the traceback in effectively the same way. In that case it |
| 13 |
> turned out to be a corrupt python bytecode file (.pyo) in their python |
| 14 |
> installation. Given that we can never rule out problems in the user's |
| 15 |
> python installation (or third party python modules), the best policy may be |
| 16 |
> to print a traceback in any case (better safe than sorry). |
| 17 |
|
| 18 |
Ok, that's fair enough. I've generalized portage_util.dump_traceback() a bit |
| 19 |
and am making use of that. Sample error output would be along the lines of: |
| 20 |
|
| 21 |
==================================== |
| 22 |
Error: Failed to import module 'cache.cdb.database' |
| 23 |
|
| 24 |
File "/usr/lib/portage/pym/portage.py", line 1285, in load_best_module |
| 25 |
mod = load_mod(best_mod) |
| 26 |
File "/usr/lib/portage/pym/portage.py", line 142, in load_mod |
| 27 |
mod = __import__(modname) |
| 28 |
File "/usr/lib/portage/pym/cache/cdb.py", line 6, in ? |
| 29 |
anksdjf |
| 30 |
name 'anksdjf' is not defined |
| 31 |
==================================== |
| 32 |
|
| 33 |
-- |
| 34 |
Jason Stubbs |
| 35 |
-- |
| 36 |
gentoo-portage-dev@g.o mailing list |
Archives