Write the checkin comment, part II previous: Impleo – a CMS I can tolerate next: Dense code In the same spirit as my previous post, can you tell what the purpose of this change is? Comments 10/25/2009 11:14 AM by Frank Quednau "Ensured I am able to get to see the darned error on startup even when the Prog is operated by a non-human user" 10/25/2009 02:10 PM by Mr_Simple I spent no more than 5 seconds looking at the code and wished the author had written a simple comment about what was suppossed to be happening. Maybe that was too simple - or perhaps my brain is just too simple to understand. 10/25/2009 02:15 PM by Ayende Rahien Mr_Simple, That is the point of this post, to see if you can figure it out :-) 10/25/2009 03:17 PM by Arne Claassen "Made error log collection configurable at runtime, rather than having it always puke to the console" 10/25/2009 03:18 PM by Ayende Rahien Arne, That is actually a very small (and relatively insignificant) change 10/25/2009 03:52 PM by Dmitry I am not exactly sure what executionOptions are but it seems like the exception should only be thrown if it happens on the server. Otherwise, the code logs the exception and then swallows it. 10/25/2009 05:06 PM by Justice "Host program fails fast (rethrow) and loud (log) if an error occurs." 10/25/2009 05:26 PM by Jarda Throw only if error happens on a server... 10/25/2009 05:29 PM by Mr_Simple @ Ayende I dont know about you, but I'd rather spend my time billing $$$ my clients than playing word association games trying to remember what the heck I programmed yesterday. It's all about zero friction when you're paying your own way. 10/25/2009 09:02 PM by Troels Thomsen @Mr_Simple I can't see why you can't do both. Keeping a tight structure will typically improve the overall quality as well as making your job easier. It's not about remembering what you did yesterday. It's about documenting what you did five minutes ago. Unless you're a goldfish, that should be an easy task. 10/26/2009 01:43 AM by Andrew Sampson Ensure that an error doesn't take down the service by trying to write to the Console (which doesn't exist for a Windows Service). 10/26/2009 02:54 AM by Andrew Use log4net to handle error logging so that we can easily capture fatal errors when necessary (along with the timestamp of the exception) Re-throw the exception when we hit a fatal Server error as we would have arrived in an unusable state Something like that :) 10/26/2009 04:24 AM by jmorris Are you trying to figure out if your audience is really reading your posts? I am guessing you expect them not to be! 10/26/2009 07:03 AM by Whut I beleve that the lacking comment should describe why we started to simetimes(!) throw exception. 10/26/2009 09:05 AM by Joe *Introduce Log4Net dependency 10/26/2009 12:28 PM by Thilak Nathen Does that even compile? You have a catch without a try. I don't know what those blue lines mean. I don't know what exception you're trying to rethrow. And yup, in the spirit of the post title... do write the check in comment.... please. 10/26/2009 04:21 PM by dave-ilsw @Thilak Nathen - That's diff output, not complete code. 10/26/2009 05:33 PM by meisinger2 The inclusion of "log4net" is a simple change in that it is nothing more than a progression in development (e.g. the next step) the "executionOptions.Action == Action.Server" is the more important change that indicates the "Host" program can now run as a Client or as a Server 10/26/2009 08:19 PM by Stuart Clearly what the code is doing is writing the exception to the logger, rather than to the console. I'd venture that the purpose is to decouple your code from the command line, or to make your code more suitable for a class library/server, rather than a console app. But this seems too obvious, so maybe I'm missing something..? 10/26/2009 10:18 PM by Chris C I would say there are two main parts to this, the first having already been mentioned and that is a service does not have a console to write the error message to. The second is when running as a service re-throw the exception so that the service manager knows the app did not terminate correctly, when running from the command line you do not wish to re-throw the exception as it will cause the Microsoft error reporting dialog to show. Though it is traditional when running from the command line, on an error to have a non-zero exit code. 10/26/2009 11:48 PM by Ayende Rahien Chris, YES! Comments have been closed on this topic.