Thread terminate

[Ervin Hegedüs]

Hi Chris,

On Thu, Aug 28, 2014 at 12:34:18PM -0700, Chris Kaynor wrote:
> On Thu, Aug 28, 2014 at 11:39 AM, Ervin Hegedüs <airween at gmail.com> wrote:
> >
> > now the code looks like this:
> >
> >   def run(self):
> >     try:
> >       connect_to_db()
> >     except:
> >       self._exit(-1, "Connection error", sys.exc_info()[1])
> >       return True
> >
> >     try:
> >       do_another_thing()
> >     except:
> >       self._exit(-2, "Another error", sys.exc_info()[1])
> >       return True
> >
> >
> You could also do this this way:
> 
> def run(self):
>     try:
>         try:
>           connect_to_db()
>         except:
>           self._exit(-1, "Connection error", sys.exc_info()[1])
>           raise # could do something similar inside self._exit instead.
> 
>         try:
>           do_another_thing()
>         except:
>           self._exit(-2, "Another error", sys.exc_info()[1])
>           raise # could do something similar inside self._exit instead.
>     except:
>         return True
> 
> I'm not sure that is any clearer.

thank's, may be I'll check this way soon,
 
> depending on what you are doing with the first two arguments to self._exit,
> the following might also work:
> 
> def run(self):
>     try:
>         connect_to_db()
>         do_another_thing()
>     except:
>         self._exit(*sys.exc_info())
>         return True

The first argument is a status, this is passed to the item, which passed
to thread - so the thread sets that status, and the main loop knows,
which item needs to pass to a thread. Eg. if the DB connection
has failed, it needs to run again, at later. But if that item is
parsed and finished (eg. table exists in db), then the item
is deletable from the queue.

> Of course, this has the issue that you do not get your extra information,
> however, from my experience, typically the error type, message, and
> traceback are sufficient, and rarely have I needed to provide additional
> details.

right, that's clear.
 
> > Now I don't see the key different between your code, and my
> > example - looks like there are same. But when I tried to throw an
> > exception, that showed in TTY. Nevermind, now it works, only the
> > necessary "return" keyword would be good to leave.
> >
> 
> Effectively, your formatting is the same as what I was suggesting - I was
> merely adding that you could wrap the entire block inside of a single
> try..except rather than having multiple ones. That does have some drawbacks
> (as mentioned above).

ok,
 
> One solution I did not mention before, but is plausible, is to
> monkey-patch/override the threading module to change the behavior
> of _bootstrap_inner or _bootstrap to behave differently. As these are on
> the Thread class, you could override them in your subclass or a base
> subclass (depending on the number of Thread subclasses you have) that
> behaves differently. Perhaps by making it call sys.excepthook. At one
> point, we discussed doing something similar at work as we normally print
> exceptions to custom streams that provide color formatting to make the
> exceptions easier to find and read (exception message printed in red,
> traceback in a dark red), as well as log.

oh, that would be a big gun - and I don't feel that knowledge to
made that with security and stability.

I think this solution will enough at first time :), I didn't used
anytime the threads (in serious project).
 

Thanks for the help,


a.


-- 
I � UTF-8