The blog is that the error message is totally unhelpful?

But I would assume the bug to be that the MessageLoggingModule was no longer creating its own queue?

I mean bug, not blog...

I think its information disclosure issue, you should not uncover implementation details, in your case you do not handle exceptions. Other exception could uncovero much more information.

If you hadn't told me that it was a bug I would have said that the Q was misnamed. I came across this recently and that was what the problem was...

Either tell me that the queue does not exist OR I do not have sufficient permissions to do the operation, but not both in a single ambiguous exception.

(?)

The framework is riddled with error messages like this. 'The file does not exist OR you do not have sufficient permissions...'

I would like to buy a stack trace.

You'll get this type of message if you have a bad queue name.

If this is a production system, I would say the bug is that the screen showed up at all. The error should have been logged and a user friendly error screen displayed.

Which Queue?

Assume your client is a blackhat.

If the exception told you that the queue exists, but you don't have permission to access it, then your server just gave the client information it shouldn't have.

It's the same as telling someone that a username is recognized, but the password is not correct. You're giving up information that gives the blackhat a clue as to how to proceed with an attack.

And yes, I realize that the custom error page can be disabled in production. But the exception could have been caught by a local subversive client app that shouldn't be running. The framework doesn't know the difference.

I don't work with MSMQ, but what the heck. It was a network exception that was incorrectly re-thrown.

Ryan,

You are correct.

This is an utterly useless error message, because when I look at it, I don't have enough context to know what caused the issue.

You forgot to create a queue before using it, didn't you?

You mean that the queues are not 'managed' with business objects? There should always be only one method that should send or received messages to a queue. Those methods can than catch the error and than you KNOW in which queue something did go wrong. You even get a ErrorCode which is a enumeration which tells you wat exactly was the problem.

I don't call that a bug, I call it bad programming! You're the programmer, so you're responsible for catching expected errors. And is it so unthinkable that when you send something to a message queue, something does go wrong?

You say the exception message is useless, I say, you should have put the MessageQueue.Send and MessageQueue.(Begin)Receive in a try/catch block. And in the catch block you always know which queue raised the exception.

this might not be common knowledge: Did you ever look into the error page's html source using the browser's "View Source"? ASP.NET provides much more details in a html comment at the bottom of the page. It might be the case that you will find the queuename there

Dave,

Hence, the bug.

I was referring to your comment on Ryan:

This is an utterly useless error message, because when I look at it, I don't have enough context to know what caused the issue.

I meant to say, that you should never have seen this exception because it should have been caught by the MessageServiceBus and should have logged it. The bus than could have raised it's own exception which can be handled by the client program (website or desktop app) or not.

As I see it, the MessageServiceBus is build a component and queue exceptions should never float to the surface, other than as an InnerException of a MessageServiceBusException.

So the exception message provided by the framework is not useless. It's only useless to you because it's caught outside the service bus and you're using multiple queues. Basicly you get the exception at the wrong place, at the wrong time.

(it was on that day that i knew Dave did not like sugar in his coffee)

+1 for Dave

i have ran into the same issue with others code before (and yes that is a fancy way of saying my code) and have thought the same exact thing

if you don't like the error message, handle the exception and throw something meaningful

Dave,

The error message from the framework is useless. If I am using 5 queues in my app, it would save me some time to know which has failed.

The bug is that I am not adding additional information to the error, but I would rather not have to do that.

Check your MS DTC settings they are likely wrong.

Component Services -> My Computer -> MSDTC -> Security Configuration

Here is the technet listing

technet.microsoft.com/en-us/library/cc753620.aspx

BTW speaking about bugs. If I found a bug in Rhino ETL, how do I report it?

Troubadour,

groups.google.com/group/rhino-tools-dev/about

The exception looks more like: It is broken and I don't have a clue what actually happened.

Exceptionhandling is one of the more difficult topics in my opinion and Microsoft can learn quite a bit when I look at this specific instance ;)