I'd like to write a hook or check-in policy to TFS, that would for example find all occurences of:
catch(Exception e)
{
MySuperLoger.LogException("some msg", params, e);
throw;
}
in the code that is being checked in, and replace those with:
catch(Exception e)
{
MySuperLoger.LogExceptionWithoutStackTrace("some msg", params, e);
throw;
}
Disregarding the point of doing that, I really need to have possibility to edit code that is part of pending changes that are being checked in.
I tried googling this, then reading Team Services service hooks events docs but it didn't help me much.
I agree with Daniel. You should not change the files based at check-in/check-out, this will cause too many issues along the way. It's also why the Check-in policies don't have an elegant way to handle these kinds of issues. Buck Hodges from the Visual Studio/TFS team once wrote a detailed blog post on why this is a bad idea.
Resharper
It's better to invest in a bit of validation code. The easiest way to do this, if you have Resharper, is to create a Search template and then save that as a inspection. With Resharper you can even do a solution wide search and replace to very quickly fix all occurrences in the code.
Choosing Replace will search the whole solution for any occurrence and will allow you to fix this in one go. Notice that this will only hit occurrences in a Catch block.
You can save this pattern and then, from the Pattern Catalog, turn it into an Inspection of the desired error level:
Using Resharper CLI you can add these inspection to a commandline based build, which allows you to integrate it with Visual Studio Team Services Build quite easily.
Roslyn
If you do not own Resharper, it's going to be a little more work, implementing a Roslyn Analyzer is a great way to handle these issues in the IDE and in the Build process, both on the client as well as on a Continuous Integration build, but will require a bit of a learning curve.
Solve the core problem
Another alternative is to simply rename the old method in your SuperLogger or to mark it [Obsolete("Use LogExceptionWithoutStackTrace instead.")]. You can tell it to throw an error as well or simply redirecting the LogException method to the method that doesn't include the stack trace by "overloading" it.
// Will result in a compiler warning when this method is used
[Obsolete("Use MysuperLogger.LogExceptionWithoutStacktrace instead.")]
public static void LogException(string msg, Exception e)
// Add , true to have the compiler throw an error when this method is used
[Obsolete("Use MysuperLogger.LogExceptionWithoutStacktrace instead.", true)]
public static void LogException(string msg, Exception e)
Or mark it obsolete and redirect at the same time:
[Obsolete("Use MysuperLogger.LogExceptionWithoutStacktrace instead.")]
public static void LogException(string msg, Exception e)
{
LogExceptionWithoutStacktrace(msg, e);
}
With Obsolete marked Resharper will automatically offer a replacement if you format the error message cleverly:
This is a case where writing a custom code analysis rule (a Roslyn analyzer, FxCop, SonarQube, whatever) and enforcing it via a gated check-in or pull request is the correct course of action. Your commit/build process should never change code.
Related
I am developing a RESTful service and I want to return 400 for all unsupported URLs.
My question is when should I choose method 1 over method 2 and vice-versa..
//method 1
public ActionResult Index()
{
//The url is unsupported
throw new HttpException(400, "Bad Request");
}
This one seems to be better?
//method 2
public ActionResult Index()
{
//The url is unsupported
return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request");
}
The second seems better as it doesn't involve exception throwing which comes at a micro-cost compared to the first example.
Being in a DevOps team, we are all in the mind-set where throwing more hardware at something to get a slightly better result is always a good cause. So I'm intentionally ignoring the micro-cost of firing a .NET exception.
If you're leveraging a telemetry framework like ApplicationInsights then just returning the status code gives you nothing more than a "failed request". It doesn't give you any useful information that allows you to either compile or get any information on the "why" of the failed request.
Telemetry platforms expect and want you to throw, because error telemetry is usually around .NET exceptions, so if you're not throwing you're creating a problem for operations.
I actually landed here, because I'm in the process of writing a Roslyn analyser and CodeFix for a project where folks love to write try{} catch { return BadRequest("put_the_reason_here"); } and neither DevOps or the Dev teams see nothing useful in the system telemetry in ApplicationInsights.
In my view you need to consider first if a request is made to the unsupported URLs. Then do you think of it is an exceptional situation or you expect that to happen? If you think of it as an exceptional situation then create and throw an exception (option 1). If you are expecting that you will receive many requests on the unsupported URL then treat it as a function of your application and use method 2.
That's said you will need to think about your clients' again if you are expecting too many requests on the unsupported URLs. In general I would prefer to throw an exception as I don't expect to receive too many requests on the unsupported URLs, and if it does happen then I would like to log it as an exception and investigate the reason.
Although this question is a bit old I figured I'd give my input since I came across this.
Errors are values. This goes for an HttpException (when unthrown) as well as an HttpStatusCodeResult. Thrown exceptions, however, create new code paths that are hidden away from your coworkers that may be one execution context higher up than yours and have to be given documentation that these code paths will be passed to them without notice. Values, however, tell you everything you need to know through their type. You can use their type in the expected execution path to tell whether an error has occured as well as find associated information with that error and log it.
I sometimes use (lightly extended) Exception's without throwing them to the next execution context to extract the useful debug information that David Rodriguez mentioned. There's never an excuse to be handing thrown exceptions to execution contexts above you that aren't actually exceptional, and this only really applies to things that are actually outside of your code's ability to handle (StackOverflowException, other fatal system exceptions, etc).
In a networked application, such as whatever MVC service you're running, the performance penalty from throwing exceptions is meaningless. The semantics and effects on maintainability, are not.
Network errors are values, and you should handle them like so.
you would throw an exception in code locations that cannot return an actionResult, such as in a controller constructor.
Can anyone please explain difference between below two approaches.
Logging in controller's OnException event:
try
{
//code
}
catch
{
//rollback trasanctions
throw;
}
Or, logging in catch block:
try
{
//code
}
catch
{
//logging here
//rollback trasactions
throw;
}
The Controller's OnException method is used when an unhandled exception occurs in the processing of the request. It is indicates what functionality should happen if an unexpected exception occurs. You should really only use this as a safeguard in the event that you messed up or the system failed in an unexpected, fatal way.
If you are executing some piece of code that you expect to throw a specific exception, wrap it in try block, and handle the specific exception accordingly. This defensive approach will help you debug issues as soon as they happen, rather than wait for them to bubble up to a point where you don't know the cause.
Think about it, if you have multiple action methods and only one OnException method per controller, then you have a much more complex issue to handle, because any of the action methods or filters could have thrown the error. However, if you catch an exception called by a specific service call then you already know exactly what caused the unexpected behavior, and it will be much easier to address accordingly.
Read this for greater understanding: Eric Lippert has an excellent article in which he breaks down the different categories of exceptions that we encounter and offers best practices for addressing them. It is available at http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx . In case you don't know who Eric Lippert is, he is very smart and you should listen to him if you code in C#. His main points are:
Don’t catch fatal exceptions; nothing you can do about them anyway, and trying to generally makes it worse.
Fix your code so that it never triggers a boneheaded exception – an "index out of range" exception should never happen in production code.
Avoid vexing exceptions whenever possible by calling the “Try” versions of those vexing methods that throw in non-exceptional circumstances. If you cannot avoid calling a vexing method, catch its vexing exceptions.
Always handle exceptions that indicate unexpected exogenous conditions; generally it is not worthwhile or practical to anticipate every possible failure. Just try the operation and be prepared to handle the exception.
Update
Just realized I didn't explicitly address the "logging" question. It probably makes most sense to avoid handling your fatal/exogenous errors in a controller scope, because you will end up duplicating your logic, often. This behavior is better handled in a global action filter.
This codeproject article Exception Handling in ASP.NET MVC explains how to override the default HandleErrorAttribute and leverage an ErrorController so that it can be applied globally.
In addition, the following 5-part blog series gives an in depth analysis of the different options you have for error handling in MVC applications: http://perspectivespace.com/error-handling-in-aspnet-mvc-3-index-of-posts
I have some integration tests written for MsTest. The integration tests have the following structure:
[TestClass]
public class When_Doing_Some_Stuff
{
[TestInitialize]
protected override void TestInitialize()
{
// create the Integration Test Context
EstablishContext();
// trigger the Integration Test
When();
}
protected void EstablishContext()
{
// call services to set up context
}
protected override void When()
{
// call service method to be tested
}
[TestMethod]
public void Then_Result_Is_Correct()
{
// assert against the result
}
}
I need to filter the code coverage results of a function by who is calling it. Namely, I want the coverage to be considered only if the function is called from a function named "When" or which has a certain attribute applied to it.
Now, even if a certain method in the system is called in the EstablishContext part of some tests, the method is marked as visited.
I believe there is no filter for this and I would like to make the changes myself, as OpenCover is... well.. open. But I really have no idea where to start. Can anyone point me in the right direction?
You might be better addressing this with the OpenCover developers; hmmm... that would be me then, if you look on the wiki you will see that coverage by test is one of the eventual aims of OpenCover.
If you look at the forking you will see a branch from mancau - he initially indicated that he was going to try to implement this feature but I do not know how far he has progressed or if he has abandoned his attempt (what he has submitted is just a small re-introduction of code to allow the tracing of calls).
OpenCover tracks by emitting a visit identifier and updating the next element in an array that resides in shared memory (shared between the profiler (C++/native/32-64bit) and the console (C#/managed/any-cpu)). What I suggested to him was (and this will be my approach when I get round to it, if no one else does and is why I emit the visit data in this way) that he may want to add markers into the sequence to indicate that he has entered/left a particular test method (filtered on [TestMethod] attribute perhaps) and then when processing the results in the console this can then be added to the model in some way. Threading may also be a concern as this could cause the interleaving of visit points for tests run in parallel.
Perhaps you will think of a different approach and I look forward to hearing your ideas.
I am using entity framework for my project with MVC as front end and I have implemented unit of work pattern with repository pattern.
I have service layer on top of repositories to handle business.
My question is where to handle exceptions?
Is it good idea to let pass through all exceptions to presentation layer and handle it in the controller or do I need to handle it in the bottom layers?
Well, the general idea is not to let UI handle all exceptions, nor that makes much sense. Lets say you have a data layer implemented with ADO.NET. The general pattern here is to handle SqlExceptions in data layer, and then wrap the SqlException in a more meaningfull DatabaseLayerException that upper layers should handle - and you follow this pattern all the way to the top, so you can have something like InfrastructureException, ApplicationException etc...
On the very top, you catch all ApplicationExceptions that went unhandled (and you make all your exceptions inherit this one for polymorphism), and you catch all unhandled Exceptions as a special case not likely to happen, and try to recover from it.
I also suggest use of logging, either manually or with AOP - you will find plenty of resources online (perhaps Log4Net ?).
I think in any exception handeling strategy you have these options:
to recover from the exception if possible (for instance server is down, wait a while and try again)
Ignore the exception because it's not serious enough or whatever other reasons.
Bubble it upwards. Multiple strategies exist here, such as just a throw; or throw new Exception("message", InnerException); to name a few.
Lastly there are the global options to log the exception to some log format, or to send an email, etc. I don't include this in the above three options, because this is global to all the above three options.
So having said that I think that at each layer in your application described above you have to ask your self in which of the above three ways can you handle the exception. If you can not recover from it or ignore it, then you should bubble it upwards to a friendly error page where you do final cleaning up and presentation of the exception.
I'm using SpecFlow, and I'd like to write a scenario such as the following:
Scenario: Pressing add with an empty stack throws an exception
Given I have entered nothing into the calculator
When I press add
Then it should throw an exception
It's calculator.Add() that's going to throw an exception, so how do I handle this in the method marked [Then]?
Great question. I am neither a bdd or specflow expert, however, my first bit of advice would be to take a step back and assess your scenario.
Do you really want to use the terms "throw" and "exception" in this spec? Keep in mind the idea with bdd is to use a ubiquitous language with the business. Ideally, they should be able to read these scenarios and interpret them.
Consider changing your "then" phrase to include something like this:
Scenario: Pressing add with an empty stack displays an error
Given I have entered nothing into the calculator
When I press add
Then the user is presented with an error message
The exception is still thrown in the background but the end result is a simple error message.
Scott Bellware touches this concept in this Herding Code podcast: http://herdingcode.com/?p=176
As a newbie to SpecFlow I won't tell you that this is the way to do it, but one way to do it would be to use the ScenarioContext for storing the exception thrown in the When;
try
{
calculator.Add(1,1);
}
catch (Exception e)
{
ScenarioContext.Current.Add("Exception_CalculatorAdd", e);
}
In your Then you could check the thrown exception and do asserts on it;
var exception = ScenarioContext.Current["Exception_CalculatorAdd"];
Assert.That(exception, Is.Not.Null);
With that said; I agree with scoarescoare when he says that you should formulate the scenario in a bit more 'business-friendly' wordings. However, using SpecFlow to drive the implementation of your domain-model, catching exceptions and doing asserts on them can come in handy.
Btw: Check out Rob Conery's screencast over at TekPub for some really good tips on using SpecFlow: http://tekpub.com/view/concepts/5
BDD can be practiced on feature level behavior or/and on unit level behavior.
SpecFlow is a BDD tool that focuses on feature level behavior.
Exceptions are not something that you should specify/observe on feature level behavior.
Exceptions should be specified/observed on unit-level behavior.
Think of SpecFlow scenarios as a live specification for the non technical stakeholder. You would also not write in the specification that an exception is thrown, but how the system behaves in such a case.
If you do not have any non technical stakeholders, then SpecFlow is the wrong tool for you! Don't waste energy in creating business readable specifications if there is nobody interested in reading them!
There are BDD tools that focus on unit level behavior. In .NET the most popular one is MSpec (http://github.com/machine/machine.specifications).
BDD on unit-level can also easily be practices with standard unit-testing frameworks.
That said, you could still check for an exception in SpecFlow.
Here are some more discussion of bdd on unit-level vs. bdd on feature-level:
SpecFlow/BDD vs Unit Testing
BDD for Acceptance Tests vs. BDD for Unit Tests (or: ATDD vs. TDD)
Also have look at this blog post:
Classifying BDD Tools (Unit-Test-Driven vs. Acceptance Test Driven) and a bit of BDD history
Changing the scenario not to have an exception is a probably good way to have the scenario more user oriented. However, if you still need to have it working, please consider the following:
Catch an exception (I really recommend catching specific exceptions unless you really need to catch all) in the step that invokes an operation and pass it to the scenario context.
[When("I press add")]
public void WhenIPressAdd()
{
try
{
_calc.Add();
}
catch (Exception err)
{
ScenarioContext.Current[("Error")] = err;
}
}
Validate that exception is stored in the scenario context
[Then(#"it should throw an exception")]
public void ThenItShouldThrowAnException()
{
Assert.IsTrue(ScenarioContext.Current.ContainsKey("Error"));
}
P.S. It's very close to one of the existing answers. However, if you try getting value from ScenarioContext using syntax like below:
var err = ScenarioContext.Current["Error"]
it will throw another exception in case if "Error" key doesn't exist (and that will fail all scenarios that perform calculations with correct parameters). So ScenarioContext.Current.ContainsKey may be just more appropriate
My solution involves a couple of items to implement, but at the very end it will look much more elegant:
#CatchException
Scenario: Faulty operation throws exception
Given Some Context
When Some faulty operation invoked
Then Exception thrown with type 'ValidationException' and message 'Validation failed'
To make this work, follow those 3 steps:
Step 1
Mark Scenarios you expect exceptions in with some tag, e.g. #CatchException:
#CatchException
Scenario: ...
Step 2
Define an AfterStep handler to change ScenarioContext.TestStatus to be OK. You may only want ignore errors in for When steps, so you can still fail a test in Then verifying an exception. Had to do this through reflection as TestStatus property is internal:
[AfterStep("CatchException")]
public void CatchException()
{
if (ScenarioContext.Current.StepContext.StepInfo.StepDefinitionType == StepDefinitionType.When)
{
PropertyInfo testStatusProperty = typeof(ScenarioContext).GetProperty("TestStatus", BindingFlags.NonPublic | BindingFlags.Instance);
testStatusProperty.SetValue(ScenarioContext.Current, TestStatus.OK);
}
}
Step 3
Validate TestError the same way you would validate anything within ScenarioContext.
[Then(#"Exception thrown with type '(.*)' and message '(.*)'")]
public void ThenExceptionThrown(string type, string message)
{
Assert.AreEqual(type, ScenarioContext.Current.TestError.GetType().Name);
Assert.AreEqual(message, ScenarioContext.Current.TestError.Message);
}
In case you are testing user interactions I will only advice what has already been said about focusing on the user experience: "Then the user is presented with an error message". But, in case you are testing a level below the UI, I'd like to share my experience:
I'm using SpecFlow to develop a business layer. In my case, I don't care about the UI interactions, but I still find extremely useful the BDD approach and SpecFlow.
In the business layer I don't want specs that say "Then the user is presented with an error message", but actually verifying that the service correctly responds to a wrong input. I've done for a while what has already been said of catching the exception at the "When" and verifying it at the "Then", but I find this option not optimal, because if you reuse the "When" step you could swallow an exception where you didn't expect it.
Currently, I'm using explicit "Then" clauses, some times without the "When", this way:
Scenario: Adding with an empty stack causes an error
Given I have entered nothing into the calculator
Then adding causes an error X
This allows me to specifically code the action and the exception detection in one step. I can reuse it to test as many error cases as I want and it doesn't make me add unrelated code to the non failing "When" steps.
ScenarioContext.Current is deprecated with the latest version of SpecFlow, it is now recommended to add a POCO to the steps test class in the constructor to store/retrieve context between steps, i.e.
public class ExceptionContext
{
public Exception Exception { get; set; }
}
private ExceptionContext _context;
public TestSteps(ExceptionContext context)
{
_context = context;
}
And in your [When] binding....
try
{
// do something
}
catch (MyException ex)
{
_context.Exception = ex;
}
In your [Then] binding, assert that _context.Exception is set and of the exception type you expected.