Ayende @ Rahien

It's a girl

Write the checkin comment, part II

In the same spirit as my previous post, can you tell what the purpose of this change is?

image

Comments

Frank Quednau
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"

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

Ayende Rahien
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 :-)

Arne Claassen
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"

Ayende Rahien
10/25/2009 03:18 PM by
Ayende Rahien

Arne,

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

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

Justice
10/25/2009 05:06 PM by
Justice

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

Jarda
10/25/2009 05:26 PM by
Jarda

Throw only if error happens on a server...

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

Troels Thomsen
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.

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

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

jmorris
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!

Whut
10/26/2009 07:03 AM by
Whut

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

Joe
10/26/2009 09:05 AM by
Joe

*Introduce Log4Net dependency

Thilak Nathen
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.

dave-ilsw
10/26/2009 04:21 PM by
dave-ilsw

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

meisinger2
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

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

Chris C
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.

Comments have been closed on this topic.