We Keep Coding

How do you finding a Attribute on a Method named in an Exception's StackTrace

This is not trying to find a method name using Method Info. I already have the method name.
The business wants a log with all the exceptions recorded. They also want each exception to have some sort of logical ID. So ops can search the documentation for ID "BusinessRule2319Violated". We also have more general type failures of course "RegisteringClientFailed".
For the specific Exceptions like the violation of a business rule we populate the Data property with the ID. Not a problem. But for more general exceptions like something unaccounted for in Registering the client threw an exception I don't want to pepper my code with hundreds / thousands of try / catches to assign a unique code.
I am thinking of decorating methods with a kind of attribute like [DefaultExceptionCodeAttribue("RegisteringClientFailed") then in the Middleware or some global exception handler crawl the e.StackTrace and find the attribute.
I've gotten as far as code that find the name of the class and method from the StackTrace, but I can't figure out how to turn that into a MethodInfo to start checking attributes.
I can sometimes use Type.GetType(string) and get something, but other times it returns null, for the same type, depending on where I call it.
I feel like I am just missing an easy way to do this.
Thanks for your time.

More flexible Assert.ThrowsException?

MSTest now allows you to test that a certain piece of code throws a certain exception type, through:
Assert.ThrowsException<MyException>(() => foo.Bar());
However, I need a more flexible exception test; I need to not only test the type of the exception, but check that its message starts with a certain string (rather than matching the exact exception string). Is there a way I can do this with MSTest? If not, what's the best way for me to do it? Is there another testing framework that handles this better?
Ideally, the Assert would take in a second func that passed in the Exception thrown, and this func could test the Exception however it wanted and return true or false to indicate that the assert had succeeded or failed.

var ex = Assert.ThrowsException<MyException>(() => foo.Bar());
Assert.IsTrue(ex.Message.StartsWith("prefix"));

Asserting against handled exceptions in NUnit

I have a method that takes a JSON object and puts it through several stages of processing, updating values in the database at each stage. We wanted this method to be fault tolerant, and decided that the desired behaviour would be, if any processing stage failed, log an error to the database and carry on with the next stage of processing, rather than aborting.
I've just made several changes to the behaviour of one of the processing steps. I then ran our unit test suite, expecting several of the tests to fail due to the new behaviour and point me at potential problem areas. Instead, the tests all passed.
After investigating, I realised that the mock data the tests run against didn't include certain key values important for the new behaviour. The tests were in fact throwing exceptions when they ran, but the exceptions were being caught and handled - and, because the tests don't run with a logger enabled, they were completely suppressed. So the new code didn't change the data in a way that would cause the tests to fail, because it was silently erroring instead.
This seems like the sort of problem that unit tests are there to catch, and the fact that they showed no trace means they're not serving their purpose. Is there any way that I can use NUnit to assert that no exception was ever thrown, even if it was handled? Or alternatively, is there a sensible way to refactor that would expose this issue better?
(Working in C#, but the question seems fairly language-agnostic)

First and foremost, in the scenario you describe, the presence or absence of exceptions is secondary. If you wrote the code to produce a desired result while catching and handling exceptions, then that result - whether it's a return value or some other effect - is the most important thing to test.
If the exceptions that you didn't see caused that result to be incorrect, then testing for the correct result will always reveal the problems. If you don't know what the expected result will be and are only interested in whether or not exceptions are getting handled, something is wrong. We can never determine whether or not anything works correctly according to whether or not it throws exceptions.
That aside, here's how to test whether or not your code is catching and logging exceptions that you wouldn't otherwise be able to observe:
If you're injecting a logger that looks something like this:
public interface ILogger
{
void LogError(Exception ex);
void LogMessage(string message);
}
...then a simple approach is to create a test double which stores the exceptions so that you can inspect it and see what was logged.
public class ListLoggerDouble : ILogger
{
public List<Exception> Exceptions = new List<Exception>();
public List<string> Messages = new List<string>();
public void LogError(Exception ex)
{
Exceptions.Add(ex);
}
public void LogMessage(string message)
{
Messages.Add(message);
}
}
After you've executed the method you're testing you can assert that a collection contains the exception(s) or message(s) you expect. If you wish you can also verify that there are none, although it seems like that might be redundant if the result you're testing for is correct.
I wouldn't create a logger that throws an exception and then write a test that checks for a thrown exception. That makes it look like the expected behavior of your code is to throw an exception, which is exactly the opposite of what it does. Tests help us to document expected behaviors. Also, what will you do if you want to verify that you caught and logged two exceptions?

Dot Net Exceptions : Null reference and argument null exception

Consider the case where a configuration (a property, in my case) is null.
public Configuration {get;set;}
if (configuration == null)
{
throw NullReferenceException("Blah blah blah..");
}
But, I read somewhere, "Dont ever throw a null reference exception in your code. NullReferenceException is a runtime exception and should only be raised by the runtime".
If it had been a argument of a function, I thought I would use a ArgumentNullException.
So, what should be the exception in this case? And speaking in general, what exceptions should be thrown at what situations? Googled this but no satisfying answers.

InvalidOperationExceptions states - The exception that is thrown when a method call is invalid for the object's current state ,which isn't a bad fit I suppose? I agree that a null reference isn't what you should throw.
here's another list of common exceptions.

The advice is correct, because a null reference exception doesn't say anything about what's actually wrong.
If the value isn't allowed to be null, then you should try to find an exception that describes what's wrong. The problem isn't that the reference is null, but the underlying reason why the reference is null.
If you can't find any exception class that is close enough, you could for example create your own ConfigurationMissingException exception.

InvalidOperationException
The exception that is thrown when a method call is invalid for the object's current state.
Which sounds like your situation.
Basically, if it's not argument related, and you want to throw a built-in exception, your choices usually come down to one of two exceptions. If you'll never be able to honor the request, NotImplementedException is appropriate. But if it's a matter of configuration or state, InvalidOperationException fits the bill.

You should throw no exceptions at what case. It only uses if happens something unexpected like you try set some null value to Configuration.
But if Configuration can be null and it already is, you should handle it out in other way.

I think there are actually three cases here:
Firstly, can this happen as a result of the user of the class doing things wrongly? Did they forget to call or set something first (i.e. is there a temporal dependency that they violated)?
If so, then I think the appropriate exception is either an InvalidOperationException, with a Message that describes how to fix the problem, or perhaps you might want to specify a Code Contract as described below.
Secondly, can this only happen due to a logic bug in the class? In other words, should it be impossible for this to happen no matter how the user of the class uses its public methods and properties?
If so, then if you are using Code Contracts you can declare this to be the case by stating:
Contract.Assume(configuration != null);
I find this to be much better. However, the exception thrown by a violation is uncatchable other than if you catch Exception. This is deliberate, and the right choice IMO.
If you're not using code contracts, then you're stuck with throwing InvalidOperationException.
Thirdly, if this exception arises naturally because of external factors outside the program's control, you should probably write a custom exception type for it if there is no existing one which matches the problem. However, for this particular example it seems unlikely that this is the case. I would expect it to be handled elsewhere.

How do I simulate throwing an exception at random point of code in Unit tests?

I've read this question about simulating throwing exceptions. Answers suggest I create a mock object that pretends being a real object.
That's not what I want to have. If I replace a real object I lose part of real code. I want to invoke real code with minimal changes and have an exception thrown from inside it at random point of that code.
Is it possible to have an exception thrown at random point of code being called from a Unit test?

don't put randomness into your unit tests. it will only bring you troubles. a unit tests should always have some consistence. especially if you want him to tell you what went wrong when he went red. if you implement a random exception throwing into your unit tests it can happen that he SOMETIMES crashes and returns a red bar. maybe the next run it the error is gone again. this is really not what unit tests are here for and you will have big troubles finding the issue for that once-occurred failed test.
a much better approach is to systematically test critical parts of your code. replace each crucial method with a mocked object, which throws the type of exception you want to test for and cover each test case like this. this will give you much more information about what went wrong when you are looking for that error.
hope this helps.

I can think about this work around.
1- Make a function called RandomException(); that throw exception if a random value is divisible by 3 otherwise it won't throw the exception. make sure this function is encapsulcate in this block of code.
#if DEBUG
void RandomException()
{
// gen random value
// if random value % 3 == 0 throw the exception now
}
#else
void RandomException()
{
}
#endif
that way when you release the code these function calls won't affect the program.
I hope that idea helps you.

It seems like you are trying to test the exception handling, i dont think this is a good approach to throw an exception randomly and check if it gets cought, if you need to test handling in certain conditions you need to simulate the condition in a real object, like an illegal situation which should cause an exception.
You still can produce this behaviour through a local varibale which you can set from outside (in your Unittest) which will cause the code to throw an exception depending on this variable, but as saied i dont think its a good approach.