exception-handling

I am currently writing a windows service that runs entirely in the background and does something every day. My idea is that the service should be very stable so if something goes wrong it should not stop but try it next day again and of course log the exception. Can you suggest me any best practice how to make truly stable windows services? I have read the article of Scott Hanselman of exception handling best practice where he writes that there are only few cases when you should swallow an exception. I think somehow that windows service is one of the few cases, but I would be happy to get some

I am experiencing a very tricky defect in my WPF application to track down. The error message is: An infinite loop appears to have resulted from repeatedly invalidating the TimeManager during the Layout/Render process. The stack trace (for what it's worth) is: at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget) at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at MS.Internal.Threading

Is this considered good programming practice in C++: try { // some code } catch(someException) { // do something } catch (...) { // left empty <-- Good Practice??? } No! That is a terrible practice! Just about the only time you should catch (...) and not rethrow the exception would be in main() to catch any otherwise unhandled exceptions and to display or log an error before exiting. If you catch (...) , you have absolutely no idea what exception was thrown, and thus you can't know whether it is safe to continue running. good practice is just: try { // some code } catch( const someException &

If you want to add an extra check not provided by argparse , such as: if variable a == b then c should be not None ...is it permissible to raise ArgumentError yourself? Or, should you raise Exception instead? Also what is common practice for this kind of situation? Say that you add a piece of code that's almost like a local extension of the library. Should you use the same exception type(s) as those provided by the library you are extending? There's nothing inherently wrong with raising an ArgumentError. You can use it anytime the arguments you receive are not what you expected them to be,

I am completely puzzled. I was so sure that .NET shuts the whole application domain if there is uncaught exception in a thread that I never tested this. However I just tried the following code and it doesn't fail... Could anyone please explain why? (Tried in .NET 4 and 3.5) static void Main(string[] args) { Console.WriteLine("Main thread {0}", Thread.CurrentThread.ManagedThreadId); Action a = new Action(() => { Console.WriteLine("Background thread {0}", Thread.CurrentThread.ManagedThreadId); throw new ApplicationException("test exception"); }); a.BeginInvoke(null, null); Console.ReadLine(); }

I want to protect our login actions by AntiforgeryToken attribute - I know why the exception from the topic occurs, however I can't seem to find any good solution for it. Let say we have the following situations: It's 8:00 AM, application users are coming to work, they sit down and starting the login process - right now it is very possible that some of the users will get the same ValidationToken . After the first one logs in - all other will see the above exception (or some other custom exception screen) when they attempt to login. Some user logged in, then accidentally pressed the " back "

if the function called by pthread_create has the following structure try{ ...code.... pthread_detach(pthread_self()); pthread_exit(NULL); }catch(...){ std::cout<<"I am here"<<std::endl; } why does the exception handler for ellipsis get called at the execution of pthread_exit ? (note that std::exception , for instance, are not thrown) eran At least in GCC pthread_exit might throw an ___forced_unwind exception, that is used for unwinding the stack during the thread exit. It does not inherit from std::exception , and therefore cannot be caught as one. If you do catch that exception, be sure to re