walkergitonga / django-chronograph

Automatically exported from code.google.com/p/django-chronograph
0 stars 0 forks source link

Better handling for exceptions #5

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I was setting up a job today and couldn't get it to work. Turns out a
permission issue on the staging server was killing it. It wasn't that hard
to find once I ran the command manually, but it would be nice if the
exceptions were just logged.
Also, the one command blowing up kept all the others from ever being run.

I attached a patch that would catch all exceptions and then add them to the
end of the stderr log. That helps with debugging, and also allows all of
the other commands to run normally when one is failing.

Some questions came up when I was writing this:
-Should the job still be marked as run if it blew up?
-Should the job be marked as failing somehow?
-Should the log have an area to indicate a failed run (some kind of boolean)?

Anyway, this would make things more usable for me. I guess the other option
is for me to stop writing code that breaks...

Original issue reported on code.google.com by alexander.j.robbins@gmail.com on 17 Mar 2009 at 3:02

Attachments:

GoogleCodeExporter commented 8 years ago
Yah, I like the idea of having some way to tell if the job ran successfully or 
not.  I think adding another field to 
keep track of the result of a run will probably be useful.  I'll play with it a 
bit and see what I can come up with.  
Thanks for the input!

Original comment by wniel...@gmail.com on 21 Mar 2009 at 4:43

GoogleCodeExporter commented 8 years ago

Original comment by wniel...@gmail.com on 10 Mar 2010 at 9:43