Ayende @ Rahien

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

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,475

filter by tags archive

Comments

J
J

have you ever thought about joining Microsoft as a tester? :)

Kelly Stuard

@J - haha - second that!

Ayende Rahien

shawn,

No, I am using the delegate passed to the async method

Justin Etheredge

If you are going to make a statement like this, then shouldn't you at least show the situation under which the error occurred? From what you have shown us, it is hard to ascertain if your claims are indeed true, or you are doing something wrong and just blaming it on the .net MSMQ apis.

Ayende Rahien

Justin,

Null Reference is almost always a bug.

In this case, I am access the AppSpecific property on a message, and it throws this error.

This is caused because of a bug in certain scenarios in which even though the queue is set to accept AppSpecific, it doesn't

James

An assert failing in production code means that some invariant somewhere is no longer true, and that the author of the code considered such a situation a bug.

Therefore Oren's statement is valid.

Justin Etheredge

@Ayende Thanks for the clarification. I didn't doubt that it was a bug on their part, I just like seeing what caused them so that I know in the future where the dragons may be.

Ayende Rahien

No, that is actually not an assert that is failing.

The assert is in my code.

The problem is that NRE.

Mr_Me

@Mr Anonymous

Hey no fair - you stole my handle.

Jeremy Gray

Though context is and always would be helpful (or at least more informative ;) ) I'm with Oren on this one. NRE == bug.

Bruno Martínez

You should stop relying in ObjectDisposedException and not touch an object after disposing it. Think of ObjectDisposedException as a debuging aide.

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. The design of RavenDB 4.0: Making Lucene reliable - 15 minutes from now
  2. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - about one day from now
  3. The design of RavenDB 4.0: Physically segregating collections - 2 days from now
  4. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 3 days from now
  5. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 6 days from now

And 13 more posts are pending...

There are posts all the way to May 30, 2016

RECENT SERIES

  1. RavenDB 3.5 whirl wind tour (14):
    02 May 2016 - You want all the data, you can’t handle all the data
  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

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats