[Tutor] Getting caller name without the help of "sys._getframe(1).f_code.co_name" ?

[Kent Johnson]

On Mon, Feb 15, 2010 at 6:07 AM, patrice laporte <zepangolin at gmail.com> wrote:

> My own experience is that there is too much coder that forget the app they
> work on is aim to be used by "real human", not by C/C++/Python/put what ever
> you want here/ guru : if your app popups to the user a message that is just
> what the traceback gave, it's not a good thing : How can it be reasonable to
> imagine the user will read that kinda message ? :
>
> Traceback (most recent call last):
>   File "<pyshell#16>", line 1, in <module>
>     a = x('foobar')
>   File "<pyshell#15>", line 3, in __init__
>     self.temp = open(fname).read()
> IOError: [Errno 2] No such file or directory: 'foobar'
>
> Of course the origin of his problem is in the message : "No such file or
> directory: 'foobar'", but a customer will never read that @ù^$#é uggly
> message, there is too much extraterrestrial words in it.

It's easy to give the user just the actual error message, either the full
 IOError: [Errno 2] No such file or directory: 'foobar'
or slightly friendlier:
No such file or directory: 'foobar'

Then log the full trackback to a file. If the user needs help, ask
them to send you the log file. They never see the full traceback and
you get all the information available.

> Traceback doesn' give more thant that, it doesn't say, as an example : we
> (the name of app) was trying to open the file "foobar" in order to do
> something with it (put here what it was supposed to do with the file) : app
> failed to open it because "foobar" doen't exist.

In a GUI app the user will often know what was happening, because they
asked to do it.

Often it is more useful to give context from the point where the
exception is caught because that is a higher-level location than the
point of failure. When you catch the exception you can tell the user
 Error processing <something meaningful to the user>
 No such file or directory: 'foobar'

This will make more sense than the low-level details of the error.

> According to me, traceback is what we need during "coding" phases, but it's
> not something to give to the user.
>
> This problem has to be solved by thinking the app in the way I'm trying to
> explain  (but not only in that way) : think about the user. This is not
> something I expect Python to do for me, I'm just looking for everything
> Python can provide me to make me think about the user.

This is a good goal. I'm not sure it requires wrapping the exception
mechanism to achieve it.

Kent