I have my client calling a WCF Server I'm hosting locally, right now I'm debugging the client so on the server I'm purposely throwing a FaultException to see how the client would handle it.
The part that is annoying is that the debugger pauses on the line that throws the FaultException. How do I get it to NOT do that? I looked in Visual Studio's Options (Debugging) and don't see anything that resembles an option for this.
Use the DebuggerStepThrough attribute on the method you wish the debugger to skip over.
You can configure the debugger to ignore certain exceptions by going to "Debug -> Exceptions" (shortcut: Ctrl+Alt+E) and unchecking "user-unhandled" for the exceptions or their namespace.
Disable either System.ServiceModel.FaultException`1 For Typed FaultExceptions (FaultException< TDetail >) or System.ServiceModel.FaultException for both typed and untyped FaultExceptions.
Find both by searching for the words "Fault" with "Find ..." or by expending "Common Language Runtime Exceptions-> System -> System.ServiceModel"
Related
Here is my problem. I am a very big fan of Design by contract, I am using this concept especially when developing libraries that can be used by other developers. I just found out a new way of doing this which is: Contract.Requires instead of Exception:
So instead of having:
public void SomeMethod(string name){
if(name==null) throw new NullArgumentException("Null values not supported");
}
I now have:
public void SomeMethod(string name){
Contract.Requires(name != null);
}
EDIT: I am working under VS2010 on debug mode.
Problem: Contract.Requires does not do anything, even when name is null!
The MSDN documentation says:
Specifies a precondition contract for the enclosing method or
property.
But nothing is specified in case the condition is not met!
I also noticed there are other Contract.Requires overloads that throw exception, display message... but then what is Contract.Requires(Boolean) for?
EDIT Answer below highlighted that a plug-in must be installed to have the full power of Contract API but then what about Mono users who want their code to behave the same on different platforms?
You should do the following:
Install the Code Contracts add-in as nfechner has noted
Go to the project properties, 'Code Contracts' folder
Check 'Perform Runtime Contract Checking'
Switch 'Assembly Mode' to 'Standard Contract Requires'
Substitute your Contract.Requires with Contract.Requires<SomeException> (the first one throws System.Diagnostics.ContractException while the second throws the exception you specified which is important for public methods)
That's the basic setup. For more accurate configuration, refer to the manual
If you use Mono, probably, Contract class is empty. I haven't done this, but chapter seven from the Contracts manual seems to explain how to provide your own implementation.
From the Contract class docs:
Important
You must install a Visual Studio add-in to enforce contracts. The Code
Contracts Premium Edition add-in lets you specify static and run-time
checking of code contracts on the project Properties page. If you do
not enable run-time checking, contracts such as the Contract.Ensures
method will not throw exceptions during run time if a contract is
violated. The Visual Studio add-in does not ship with Visual Studio
2010 or the Windows SDK.
With a message like this it is usually helpful to specify exactly what you have done.
For example, you do not mention in the original message if you have installed the VS Addon, nor that you have enabled it under your project properties, or that you are actually running in debug vs release mode, etc.
Re Contract.Requires vs Contract.Requires<Exception>
Contract.Requires is recommended.
According to the manual
If your code must throw a particular exception on failure of a
particular precondition, you can use the generic overloaded form
below. (Please read Section 5.1 before committing to this form in your
code. You cannot use Requires < Exn <Exn>> without running the contract tools
on all builds. If you do, you will get a runtime failure everytime.)
I have a situation where I get an exception in a dynamic assembly, which in turn terminates my application. I assume this assembly is generated by some of the third party libraries we use, because we don't use Reflection.Emit or other codegen tools ourselves. However, as far as I can tell, there is no way for me to determine where it comes from?
This is the exception I get:
An unhandled exception of type 'System.ArgumentException' occurred in Unknown Module.
Additional information: An item with the same key has already been added.
Is there tooling, or some code I can write into my own application, to figure out what is going on?
Go to Debug -> Exceptions:
Exceptions dialog http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-82-17-metablogapi/5824.image_5F00_thumb.png
then check the Thrown checkbox on the Common Language Runtime Exceptions line (or directly on the ArgumentException line). This will make the debugger kick in as soon as any exception is thrown, before the stack is unwinded. You'll be able to examine the call stack at this point.
Note that you may also have to disable the following option:
Tools -> Options -> Debugging -> General -> Enable Just My Code
And in the call stack window, enable Show External Code from the context menu:
call stack context menu http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-82-17-metablogapi/5672.image_5F00_thumb_5F00_3.png
I have a number of Contract.Assert statements in my code. When in Debug Mode, the assertions that fail throw an assertion failed dialog.
There are two things I don't understand about this:
Are Contracts not controlled by the Rewiter? So I thought if that it was unchecked, that no Contracts would be enforced. If this is not the case, what is controlled by the Runtime checking checkbox? What is not?
Why is an Assertion dialog thrown? They seem kind of useless, as in Silverlight, all I get is a IE dialog saying that an assertion has failed. I would prefer an exception.
Greg
The Contract.Assert method is also enabled under DEBUG, that's why you get the failure. Under Release, you should not see it.
If you want something other than the dialog, you need to either enable the rewriter, or register a handler with the ContractFailed event handler.
1 - A Contract is a contract, he must be accomplished although if it´s not necessary why use contract? Maybe you could use null labels values in the contract.
2 - Asserting do exactly this, show for the developer there is something going worn, this is mostly used in development environment, when you put in production remember to build in release to exclude this validation from the IL .
I've recently started using a private NuGet server to manage my organization's internal libraries. This means in order to step into our own code that is in a library, I need to disable "Enable Just My Code" in debugging options since we aren't referring to the projects directly any more. This is a pretty hefty MVC project that uses dynamic types and ExpandoObjects in addition to ViewBag. I get two RuntimeBinderExceptions for every single use of a dynamic type... which is a lot. This appears to be normal behavior from what I've read. Normal it may be, but useful it is not.
My first thought was to disable this particular exeption in the Debug-> Exceptions dialog. The exception is not to be found there. I can't figure out any way to be able to step outside the projects referenced directly, without also opening myself up to these exceptions. (And all manner of other low-level framework exceptions that I don't want to hear about, but this is the biggest offender by far).
What's the best way to deal with this?
Edit: This is the problem. How do I stop this with "Enable Just My Code" disabled?
You can add additional "exception" names (existing in your own code or other libraries)...so long as you know the exception's fully qualified type name.
Managing Exception with the Debugger
https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx
In Visual Studio 2010
Via the Debug | Exceptions... dialog.
Use the Add button to add a new exception under the Common Language Runtime Exceptions group and call it Microsoft.CSharp.RuntimeBinder.RuntimeBinderException
then just make sure Thrown and User-Handled are NOT ticked - thus causing the first chance exception to be ignored, rather than being caught by the debugger.
In Visual Studio 2017
Via the Debug | Windows | Exception Settings... panel
Use + to add the new exception name
make sure it's unticked
After reading about the System.Diagnostics.Contracts.Contract static class that has been influenced by the awesomeness of Spec# I was thrilled and immediately started peppering my code with calls to Contract.Requires() and Contract.Ensures().
I guess it's just because my code is so super-awesome and bug-free that checking that those calls actually did something just didn't come up until recently. A bug slipped through and I came to the realization that these calls do not do anything! I would have thought that they at least throw an exception when the condition is violated but no such luck.
Am I missing something? Does anyone know what the heck is the point?
From the Contract Class page at MSDN:
You must use a binary rewriter to
insert run-time enforcement of
contracts. Otherwise, contracts such
as the Contract.Ensures method can
only be tested statically and will not
throw exceptions during run time if a
contract is violated. You can download
the binary rewriter CCRewrite from
Code Contracts on the MSDN DevLabs Web
site. CCRewrite comes with a Visual
Studio add-in that enables you to
activate run-time contract enforcement
from the project Properties page. The
binary rewriter and the Visual Studio
add-in do not ship with Visual Studio
2010 or the Windows SDK.
Expanding on JSBangs' answer:
You must check the "Perform Runtime Contract Checking" box here:
(I also checked the "Static Checking > Peform Static Contract Checking" box)
If you want the .Requires call to throw an error you need to set an option in project settings or use .Requires<T> call