We are in the process of switching over our codebase to have the Check for arithmetic overflow/underflow option turned on by default and we've run into problems with our DevForce queries.
I'm able to reproduce the problem with a very basic query such as this against the NorthwindIB database:
var coolProducts = em.Products.Where(p => p.UnitsInStock == 42).Execute();
By doing some debugging, it looks like DevForce is trying to add that query to the cache which involves making a hash code for the query. The class that does that hash code generation (ExpressionHashCodeCalculator) is missing a switch case for the ConvertChecked ExpressionType and so it throws an ArgumentException saying "Unknown Expression type".
It seems the compiler sprinkles that ConvertChecked thing all over the place in expressions when you are running in a checked context.
Thanks for reporting this. It will be fixed in the next release, due in March.
I have a customer report of an IndexOutOfRangeException but the line number at which it is reported has no array access! The line is of the form:
using (XyzConnection conn = new XyzConnection(anObject.aProperty.anotherProperty))
XyzConnection, anObject, etc are made up replaced names but the construct is essentially same.
Can the above itself throw IndexOutOfRangeException?
Is it possible that the array access (and exception) are in some code called from above line, i.e. the constructor or one of the property getters? How can I identify the correct location?
I should mention that the problem cannot be reproduced in development environment and I cannot install Visual Studio on the customer's machine.
Can the above itself throw IndexOutOfRangeException?
That line can't in and of itself throw the exception.
Some code inside the XyzConnection constructor method could be doing it, Or, the property getter for anObject.aProperty could be throwing it, or the property getter for aProperty.anotherProperty could also be throwing. My bet would be that it is one of the property getters.
They could be being inlined by the JIT compiler, and hence you wouldn't see them in the stack trace, no matter what PDB's you had. This is actually quite common, as propert getters are usually small and simple, which makes them ideal candidates for inlining.
I'd recommend a solid code review of those 2 property getters, followed by the XyzConnection constructor
The first thing that comes to mind is that the PDB doesn't match the DLL version being used. Nothing about the line of code hints at an Index Out of Range exception. Without seeing the code surrounding that call, and the constructor declaration itself, I doubt there's much help people can give.
One other thing to check in terms of misleading line numbers, if the code is using try/catch blocks, ensure that catch blocks that are re-raising exceptions are using "throw;" not "throw ex;" (where ex is the caught exception.) This causes the exception trace stack to be re-generated. (both time consuming, and overwrites potentially useful info.)
I have a class 'b' that inherits from class 'a'. In class 'a' there is some code that performs an action if an event is not null. I need that code to fire in class 'b' during specific times in the application. So in 'b' I subscribed to a new Handler(event).
If I leave the autogenerated event 'as is' in class 'b' with the throw new NotImplementedException(); line, the code works/runs as expected. As soon as I remove the thow exception, the application no longer works as expected.
So, what is the throw new NotImplementedException doing besides throwing the exception?
I realize I'm probably trying to solve my coding problem the wrong way at this point, and I am sure I will find a better way to do it (I'm still learning), but my question remains. Why does that line change the outcome of code?
EDIT:
I reallize I wan't very specific with my code. Unfortunately, because of strict policies, I can't be. I have in class 'a' an if statement.
if (someEvent != null)
When the code 'works', the if statement is returning true. When it isn't working as expected, it is returning 'false'. In class 'b', the only time the application 'works' (or the if statement returns true), is when I have the throw new NotImplementedException(); line in class 'b's event method that is autogenerated when I attached the new event.
Think about this: what if you want to add two integers with the following method...
private int Add(int x, int y)
{
}
...and have no code inside to do such (the method doesn't even return an integer). This is what NotImplementedException is used for.
NotImplementedException is simply an exception that is used when the code for what you're trying to do isn't written yet. It's often used in snippets as a placeholder until you fill in the body of whatever has been generated with actual code.
It's good practice to use a NotImplementedException as opposed to an empty block of code, because it will very clearly throw an error alerting you that section of your code isn't complete yet. If it was blank, then the method might run and nothing would happen, and that's a pain to debug sometimes.
It is simply an exception, as for why it means your application "works" is entirely dependent on the code handling any exceptions.
It is not a "special" exception as opposed to a normal exception (other than being derived from Exception like the rest). You tend to see it with code generation as a placeholder for implementing the member it is throwing inside. It is a lot easier to do this than have code generation try to understand the member structure in order to output compiling code.
When you say "no longer works as expected", I am assuming it compiles. If removing this stops the code from compiling then the chances are good you have a compilation error about a return value.
Perhaps the code that triggers the event expects a certain response from handlers, or if there are no handlers or exceptions occur it defaults the response and carries on. In your case, there is a handler and no exception so it expects a better response?
Complete guesswork.
If there is code in a that you need to use in b, consider making the method that houses the code protected and optionally virtual if you need to override the behaviour.
NotImplementedException, I believe, has a little special meaning: "this code is still in development and needs to be changed". Developers put this exception to make some code compileable, but not executable (to avoid data damage).
Information about this exception type can be found in documentation, it explains the meaning very detailed: https://learn.microsoft.com/en-us/dotnet/api/system.notimplementedexception?view=netcore-3.1
Some development tools, like Resharper, for example, generates new members with NotImplementedException inside, thus protecting you from execution the code, which is not ready. Same time they highlight this exceptions same way as "//todo:" comment
For other situations, for example, when you don't need to implement an interface or virtual member, or may be, you don't implement some paths in switch/case, if/else etc statements, you probably will use NotSupportedException, OutOfRangeException, ArgumentNullException, InvalidOperationException etc.
At the end, consider this situation to understand the purpose of NotImplementedException:
We are writing banking application, and, at the moment, implementing money transferring feature, we have:
public void Transfer(sourceAccount, destAccount, decimal sum)
{
sourceAccount.Credit(sum);
destAccount.Debit(sum);
}
Here we are calling two methods which do not exist yet. We are generating both with default NotImplementedException, and going to first one (Credit) to implement it. Lets say, implementation took some time, we have written test for it, and even have done several manual tests. We completely forgot about second method "Debit" and deploying our application to beta, or even to production. Testers or users start using our application and soon they are coming to money transfer functionality. They are trying to call Transfer, which shows them a general message "We are so sorry, we got some errors", same time we, as a developer team, receive notification about NotImplementedException happened with the stack trace pointing us to the method "Debit". Now we are implementing it, and releasing new version, which can do money transfers.
Now imagine, what would happen, if there was not an exception there: users would spend lot of money trying to do that transfers, trying several times, each time throwing money in to a hole.
Depending on the purposes of the application it can be bigger or smaller problem: may be button on your calculator does not work, or may be that was scientific calculator and we just missed some important math while calculating vaccine code against some aggressive virus.
The NotImplementedException is a way of declaring that a particular method of an interface or base class is simply not implemented in your type. This is the exception form of the E_NOTIMPL error code.
In general an implementation shouldn't be throwing a NotImplementedException unless it's a specifically supported scenario for that particular interface. In the vast majority of scenarios this is not the case and types should fully implement interfaces.
In terms of what it's doing though. It's simply throwing an exception. It's hard to say why the program keeps function in the face of the exception and breaks without it unless you give us a bit more information.
I'm making a database call with linq and it is returning some results to me. Following is the code for the same:
var resultSet = DataContext.GetList(id);
foreach(var result in resultSet)
{
// do something here with result
}
After this, I try to access again same resultSet as below:
foreach(var result in resultSet)
{
// do something here with result
}
When I'm in debug mode it doesn't throw any error, instead it simply exits debug mode and execution is completed and focus comes back to page.
I want to know why it is not throwing any error in debug mode that I'm using the enumeration for the second time? Am I missing anything? All other errors are throwing exceptions even in the debug mode.
Update: I intentionally didn't do that second calling. It was done by mistake, but it took sometime for me to find that error, if it would have thrown an error, then I would have easily fixed it. This is reason I posted this question here.
Note: I'm doing this throw a ajax call.
I think if you go to Debug (Menu)> Exceptions and check the checkbox under Thrown for Common Language Runtime Errors. Now Visual Studio debugger should break when the error occurs and you should be able to see what's happening.
I have a class "Address" that has the following check:
if(thisAddress == null)
thisAddress = new Address();
When the code is run I get "Index was outside the bounds of the array" on the first line. If I remove the IF statement I get the error on the second line.
The class comes from Linq to SQL, but I have extended it. This worked before, I'm not sure why it started happening all of a sudden. thisAddress is a private variable in a UserControl.
Any ideas?
The code is not in sync with the binary.
Try recompiling the assembly that contains the usercontrol.
Has anything changed in the DB that you think can break the LINQ to SQL mapping?
Typically linq statements are executed lazily, or when they are used rather than when you wrote the link. Therefore it is entirely possible that the code executing behind the If statement is actually where the fault lies.
If this is the case then you could try stepping into the statement (it could be using an equality check on the thisAddress class) and the debugger should show you the linq being executed.
An alternative and what I use mostly, is setting the debugger to break when exceptions are thrown rather than when they are unhandled, this is a pretty good way of tracking down this sort of issue. (Debugger/Exceptions tick when thrown in VS).
hope that helps
Figured it out. Apparently I left out a crucial piece of information. The code is inside the get {} section for a control property. The error was a different line in the code (where I was using a split()), but the debugger pointed to the first line of the get{} statement.