"Ensured I am able to get to see the darned error on startup even when the Prog is operated by a non-human user"

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.

"Made error log collection configurable at runtime, rather than having it always puke to the console"

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.

"Host program fails fast (rethrow) and loud (log) if an error occurs."

Throw only if error happens on a server...

@ 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.

@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.

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).

• 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 :)

Are you trying to figure out if your audience is really reading your posts? I am guessing you expect them not to be!

I beleve that the lacking comment should describe why we started to simetimes(!) throw exception.

*Introduce Log4Net dependency

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.

@Thilak Nathen - That's diff output, not complete code.

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

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..?

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.