Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,130 | Comments: 45,558

filter by tags archive


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"


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.

Ayende Rahien


That is the point of this post, to see if you can figure it out :-)

Arne Claassen

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

Ayende Rahien


That is actually a very small (and relatively insignificant) change


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.

Troels Thomsen


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.

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

  • 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

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.


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

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.

Comment preview

Comments have been closed on this topic.


  1. How to waste CPU and kill your disk by scaling 100 million inefficiently - 11 hours from now
  2. RavenDB Conference 2016–Slides - about one day from now

There are posts all the way to Jun 01, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats