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,124 | Comments: 45,473

filter by tags archive

Errors are part of your experience

time to read 2 min | 341 words

The NH Prof website is running on Rhino Service Bus. I decided that this is a great time to test Rhino Service Bus for real, and I built the website on top of it. Even the order processing is done on top of RSB.

But that isn't what I wanted to talk about today. I wanted to talk about errors, and how important they are. In this case, I screwed up when I build the error reporting capability for NH Prof, which means that if you tried to report an error back, you would get a nasty 404 and I would get nada as feedback.

The actual fault is not relevant, and it is fixed already, so hopefully you'll forgive me for having bugs in a beta product.

What I really wanted to talk about was how I fixed the issue. Remember, this is the production machine, and I have no debugger there. What I did was go to the MSMQ interface, go to the back end queue and take a peek in the errors sub queue, where I got to see the following:


The first message is the original one, the second is the error description for it. When I opened it, I could see that the error was "AyendeIsStupidException", which explained exactly what went wrong, and I was able to quickly resolve the issue by buying more IQ on eBay. I then moved the message back to the main queue, and got the email that I expected about the problem with NH Prof.

A few important points about this:

  • No debugging
  • No hunting through the logs
  • No custom tools. Rhino Service Bus Profiler doesn't exist (yet).
  • In your face, explicit and very quick troubleshooting experience.

Error handling was an explicit design goal when I set to build Rhino Service Bus, and I am happy to be able to say that so far, it is proving that it is working, and is definitely worth the time I spent in it.


Jason Whitehorn

In the past I've used log4net for logging, which works OK. But log files often have a way of becoming burdensome to wade through, so more often than not important errors are not seen.

This is definitely an interesting take on the idea of logging. Are you (or have you thought about) using message priority to represent the error severity so that more critical errors bubble to the top?


I've been using ActiveMQ for some time now to store error requests as well. I wrap them up in a SOAP Fault storing details about the error as well as the 'error request'.

The benefit of using MQ's for error handling is that you can deal with your errors programmatically, i.e. once you have fixed the bug that caused the error you can replay the 'error request' to ensure it works and if its a 'Store Message' its still processed (i.e. Store and forward) so you don't lose any important messages.


I hope to see you continue to update the Rhino Service Bus and it's sample (dummies like me need samples... lol) - it's a great setup and I'm looking forward to adding this capability into my applications

Ayende Rahien


No, I am not.

A failure is a failure is a failure.

It depends on the semantics of the app to decide what to do with it.

Rhino Service Bus simply make sure that the information is accessible and easy to view.

Ayende Rahien


Absolutely. I was able to replay all failed transactions!

Ayende Rahien


I intend to do so, but I am trying to juggle quite a few balls at the moment.

It will get there, but it will take time

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 whirl wind tour: You want all the data, you can’t handle all the data - about one day from now
  2. The design of RavenDB 4.0: Making Lucene reliable - 3 days from now
  3. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 4 days from now
  4. The design of RavenDB 4.0: Physically segregating collections - 5 days from now
  5. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 6 days from now

And 14 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    29 Apr 2016 - A large cluster goes into a bar and order N^2 drinks
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  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