We Keep Coding

Overflow exception double into int

In debugging mode this line of code double divided by int result in an System.Overflow exception. The value for the int32 was too small/large.
The result of 0.0d/0 is NaN. Which does not fit into a int obviously.
int result = Convert.ToInt32(0.0d/0);
But how do I handle that scenario correctly that no exception happens? Or should I try catch it?

The byte size of an int is too small to fit all possible double values. See Data Types. Your best option is to carry out the conversion in a try-block and catch the OverflowException.
try
{
int result = Convert.ToInt32(0.0d/0);
}
catch (OverflowException)
{
//...
}

I'd say that depends entirely on your applications expectations.
If you know the double can be NaN or just larger than Int32.MaxValue and you like the function to continue with a specific result, you should write a check.
If an overflow is an actual exception that needs to be handled up-stack by some special logic, you should throw an exception.

You know what this calculation is supposed to calculate, so you should be already able to decide if 'NaN' is OK and what should be put into that int when such result occurs. You may catch it. You may add ifs to make sure it doesnt happen. You may leave it. You may do whatever you need, but first, you need to decide what you want to occur when a 0.0 happens. It is there for some reason.
Seeing 0.0/0.0 usually mean an error earlier in the code. 0/0 almost never makes sense, hence Not-a-Number is the result to remind about it.
In general, you may want to trace and diagnose why the division-by-zero occurred. Check why the second variable is zero (why was that /0.0 and not i.e. /1.0 ?), decide if it is a valid possible value and if it is not OK then fix the code responsible for that zero, so zero won't occur at all.
For instance, if you had a formula forcepower(x,z) / distance(x,z) and both the power and the distance turned out to be zeros because x and z were the same point, then you may add an if checking x==z and force the result to be 0.0 in such case. But, if that formula calculated foobarized whachamacallit then you should pick the most frublastic number. I don't know. You should.
---edit
Ok, after your comments I understand it now. So you've got control over all values that are used in division - good!
Since you already test 'bar' for zero and in this case force 'foo' to zero (I've seen your comment about 'because nothing can be calculated then') then the problem is in fact in the way you have designed, or, 'encoded' the results.
Forcing something to 0.0 or 0 isn't a really good way of indicating that "nothing was calculated". In later parts of the code you will have a hard time telling if the bazz is 0 because it was the result, or because it was not calculated.
Sure, of course, if 0 is an actually invalid value that normally can never occur, then its sometimes ok to use it as a special "nothing"-indicating value..
..but as you saw from that 0/0 case, it can cause inobvious problems, and also it will force you to remember to check in every place if 'values are good':
double foo;
if(bar != 0) foo = calculate_the_foo(); // check the Bar maybe it's zero
else foo = 0.0; // can't calculate, no foo
double z;
if(bar != 0) z = foo/bar; // added a check against zero in bar again..
else z = ...um? what to use here.. 0 again?
int result = Convert.ToInt32(z);
// later in the code
if(result != 0) //..again? but.. is it result of 0 or no result?
..
// and so on
It is very easy to forget to check for special values and to simply write result = foo/bar and get Infinites, NaNs or Overflows.
Therefore, it is much better to use a 0 to really mean normal zero and to use a proper no-value thing for indicating a missing data..
..and the simplest one is plain old ... null.
If you use nullables like int? or double?, then you can simply write things like:
using System.IO;
using System;
class Program
{
static void Main()
{
double? foo = 5.0;
double? bar = 4.0;
double? result = foo/bar;
Console.WriteLine("x/y: " + prettynulls(result));
// ^writes: 1.25
foo = null;
bar = 4.0;
result = foo/bar;
Console.WriteLine("null/y: " + prettynulls(result));
// ^writes: (null)
foo = 5.0;
bar = null;
result = foo/bar;
Console.WriteLine("x/null: " + prettynulls(result));
// ^writes: (null)
foo = null;
bar = null;
result = foo/bar;
Console.WriteLine("null/null: " + prettynulls(result));
// ^writes: (null)
}
private static string prettynulls(double? val)
{
return val == null ? "(null)" : val.ToString();
}
}
Please observe that you can even do operations like +-/* on them without tons of ifs to check for nulls. Mathematic operations simply will return null if one operand was null. Hence your case would become:
double? foo;
if( ... ) foo = calculate_the_foo();
else foo = null;
int? result = (int?)( foo/bar );
of by making the calculate smart with nullables when foo can't be calculated:
double? foo = calculate_the_foo();
int? result = (int?)( foo/bar );
Look at the simplicity and expressiveness. Nullables like double? even handle casting. A double? that holds a null, when casted to int? will simply be return null. Otherwise it will cast the double value to int and return int.

What is the C# "checked" keyword for?

I just came across this keyword for the first time. What does it do, and when should it be used?
int multiply(int i, int j)
{
return checked(i * j);
}

Eric Lippert has a two-part blog post "What is the unchecked keyword good for?": Part 1 -- Part 2
"Checked" is a block keyword that enables arithmetic overflow checking. Normally, if an integer operation exceeds the maximum or minimum value that the type can handle, the operation proceeds anyway, and the result just cycles like an odometer. So, for example:
byte b = byte.MaxValue;
Console.WriteLine(b); // 255 (11111111)
Console.WriteLine(++b); // 0 (00000000)
Placing this snippet in a checked block prevents the overflow, and instead the runtime throws an OverflowException:
checked
{
byte b = byte.MaxValue;
Console.WriteLine(b); // b=255
try
{
Console.WriteLine(++b);
}
catch (OverflowException e)
{
Console.WriteLine(e.Message); // "Arithmetic operation resulted in an overflow."
// b = 255
}
}
And since there's a compiler option /checked, which turns compiler checking on by default, there is also the unchecked keyword which prevents overflow checking.
As far as usage, overflow checking should be used sparingly, as is true of exception handling in general. To check for an overflow at runtime, it's significantly faster (like, an order of magnitude) to do a simple check, rather than to turn on overflow checking:
int multiply(int i, int j)
{
if ((long)i * (long)j > int.MaxValue)
throw new InvalidOperationException("overflow");
return i*j;
}
You can do this even for Int64/long, using BigInteger (this can be still at least an order of magnitude faster than using checked):
long multiply(long i, long j)
{
if (new System.Numerics.BigInteger(i) + j > long.MaxValue)
throw new InvalidOperationException("overflow");
return i*j;
}
There's also a good Code Project article on this that explains some caveats (eg, the overflow check only applies to the immediate code block, not to any function calls inside the block).

Implementing parallel exceptions to get trees of errors?

Consider the following code:
// this method should add numbers, the requirements are:
// x >= 3 and y <= 5
int add(int x, int y)
{
if(x < 3) throw new ...;
if(y > 5) throw new ...;
}
It's absolutely traditional approach, but in case you pass invalid values for both x and y, you'll only get an exception for x. Why x and not y? Just because you first check x and only then y. Why? That's basically the main question.
In the code above, there's absolutely no sense in checking x before y or y before x. Just because the idea of execution flow in a single thread, some statements are executed before others.
I'm thinking about implementing a mechanism for working with parallel exceptions. The idea is, if there are 2 statements that can be executed simultaneously (execution order doesn't matter) and both of them throw exceptions, I'd like to be able to handle all these exception. The pseudo-code is like following:
// this method should add numbers, the requirements are:
// x >= 3 and y <= 5
int add(int x, int y)
{
parallel
{
if(x < 3) throw new ...;
if(y > 5) throw new ...;
} // point A
return x + y;
}
Somewhere at point A the cumulative exception is thrown. Have you ever seen this approach before, or may be even implemented something of that kind? The main goal here is that if you have a complicated operation, that uses a number of another operation, and the "topmost" operation fails for some reason, you're able to get full diagnostics for what was wrong: not a single error (or a number of nested errors), but a tree of errors.
The questions are:
What do you think?
Have you seen it before?
Have you tried implementing something similar?

Perhaps use an AggregateException?

You seem to want to enforce a set of business rules.
One approach is to create a collection of broken rules and add specific broken rules (e.g. input too short, input must be alphanumeric) as separate elements of that collection, then throw a BrokenRulesException that includes the collection of broken rules as a parameter.
That allows the caller to fully understand what's wrong with the input without changing any language semantics.

Whats wrong with:
int add(int x, int y)
{
if(x < 3 || y > 5)
throw new Error("Incorrect Parameter, x must be >= 3 and y must be <= 5");
}

I think that this would be extraordinarily difficult without implementing something called a continuation -- the ability to return the current state of a function for delayed execution.
Basically, the problem is that instead of an exception (or, rather, a thrown... thing as you do not always have to throw an Exception object in all languages) being a message that a point which cannot be handled has been reached, it would have to return both that and the ability to force continuation past that point anyway. (Thus, you would need continuations)
Additionally, at least on the lower level, this would force the language to always throw an object in those cases. Throwing an int, on the other hand, is occasionally useful.
All of that said, there is nothing stopping you from, say, implementing a macro which works similar to how you've described.

// this method should add numbers, the requirements are:
// x >= 3 and y <= 5
int add(int x, int y)
{
if(x < 3 && y > 5) throw new ...;
if(x < 3) throw new ...;
if(y > 5) throw new ...;
}

Can't this be fairly easily done, without the need for AggregateExceptions or similar:
string ErrorMessage="";
if(x<3) ErrorMessage += "x must be >=3\n";
if(y>5) ErrorMessage += "y must be <=5\n";
if(ErrorMessage!="") throw new Exception(ErrorMessage);
if a string is too simple, it's easy to do something similar with a more complex object type.

What is the best way to calculate a formula when using an int as a divisor

Often I find myself having a expression where a division by int is a part of a large formula. I will give you a simple example that illustrate this problem:
int a = 2;
int b = 4;
int c = 5;
int d = a * (b / c);
In this case, d equals 0 as expected, but I would like this to be 1 since 4/5 multiplied by 2 is 1 3/5 and when converted to int get's "rounded" to 1. So I find myself having to cast c to double, and then since that makes the expression a double also, casting the entire expression to int. This code looks like this:
int a = 2;
int b = 4;
int c = 5;
int d = (int)(a * (b / (double)c));
In this small example it's not that bad, but in a big formula this get's quite messy.
Also, I guess that casting will take a (small) hit on performance.
So my question is basically if there is any better approach to this than casting both divisor and result.
I know that in this example, changing a*(b/c) to (a*b)/c would solve the problem, but in larger real-life scenarios, making this change will not be possible.
EDIT (added a case from an existing program):
In this case I'm caclulating the position of a scrollbar according to the size of the scrollbar, and the size of it's container. So if there is double the elements to fit on the page, the scrollbar will be half the height of the container, and if we have scrolled through half of the elements possible, that means that the scroller position should be moved 1/4 down so it will reside in the middle of the container. The calculations work as they should, and it displays fine. I just don't like how the expression looks in my code.
The important parts of the code is put and appended here:
int scrollerheight = (menusize.Height * menusize.Height) / originalheight;
int maxofset = originalheight - menusize.Height;
int scrollerposition = (int)((menusize.Height - scrollerheight) * (_overlayofset / (double)maxofset));
originalheight here is the height of all elements, so in the case described above, this will be the double of menusize.Height.

Disclaimer: I typed all this out, and then I thought, Should I even post this? I mean, it's a pretty bad idea and therefore doesn't really help the OP... In the end I figured, hey, I already typed it all out; I might as well go ahead and click "Post Your Answer." Even though it's a "bad" idea, it's kind of interesting (to me, anyway). So maybe you'll benefit in some strange way by reading it.
For some reason I have a suspicion the above disclaimer's not going to protect me from downvotes, though...
Here's a totally crazy idea.
I would actually not recommend putting this into any sort of production environment, at all, because I literally thought of it just now, which means I haven't really thought it through completely, and I'm sure there are about a billion problems with it. It's just an idea.
But the basic concept is to create a type that can be used for arithmetic expressions, internally using a double for every term in the expression, only to be evaluated as the desired type (in this case: int) at the end.
You'd start with a type like this:
// Probably you'd make this implement IEquatable<Term>, IEquatable<double>, etc.
// Probably you'd also give it a more descriptive, less ambiguous name.
// Probably you also just flat-out wouldn't use it at all.
struct Term
{
readonly double _value;
internal Term(double value)
{
_value = value;
}
public override bool Equals(object obj)
{
// You would want to override this, of course...
}
public override int GetHashCode()
{
// ...as well as this...
return _value.GetHashCode();
}
public override string ToString()
{
// ...as well as this.
return _value.ToString();
}
}
Then you'd define implicit conversions to/from double and the type(s) you want to support (again: int). Like this:
public static implicit operator Term(int x)
{
return new Term((double)x);
}
public static implicit operator int(Term x)
{
return (int)x._value;
}
// ...and so on.
Next, define the operations themselves: Plus, Minus, etc. In the case of your example code, we'd need Times (for *) and DividedBy (for /):
public Term Times(Term multiplier)
{
// This would work because you would've defined an implicit conversion
// from double to Term.
return _value * multiplier._value;
}
public Term DividedBy(Term divisor)
{
// Same as above.
return _value / divisor._value;
}
Lastly, write a static helper class to enable you to perform Term-based operations on whatever types you want to work with (probably just int for starters):
public static class TermHelper
{
public static Term Times(this int number, Term multiplier)
{
return ((Term)number).Times(multiplier);
}
public static Term DividedBy(this int number, Term divisor)
{
return ((Term)number).DividedBy(divisor);
}
}
What would all of this buy you? Practically nothing! But it would clean up your expressions, hiding away all those unsightly explicit casts, making your code significantly more attractive and considerably more impossible to debug. (Once again, this is not an endorsement, just a crazy-ass idea.)
So instead of this:
int d = (int)(a * (b / (double)c)); // Output: 2
You'd have this:
int d = a.Times(b.DividedBy(c)); // Output: 2
Is it worth it?
Well, if having to write casting operations were the worst thing in the world, like, even worse than relying on code that's too clever for its own good, then maybe a solution like this would be worth pursuing.
Since the above is clearly not true... the answer is a pretty emphatic NO. But I just thought I'd share this idea anyway, to show that such a thing is (maybe) possible.

First of all, C# truncates the result of int division, and when casting to int. There's no rounding.
There's no way to do b / c first without any conversions.

Multiply b times 100. Then divide by 100 at the end.

In this case, I would suggest Using double instead, because you don't need 'exact' precision.
However, if you really feel you want to do it all without floating-point operation, I would suggest creating some kind of fraction class, which is far more complex and less efficient but you can keep track of all dividend and divisor and then calculate it all at once.

How do I gracefully test for overflow situations in C#?

Update: I'm going to leave it as is: The performance hit of a exception (very rare) is better than the probably performance hit for checking on each operation (common)
I'm trying to support an "EstimatedRowCount" that in one case would be the product of two sub-cursors that are joined together:
estimatedRowCount = left.EstimatedRowCount * right.EstimatedRowCount;
return estimatedRowCount;
Of course, if left and right are big enough, this will throw an OverflowException.
Here, I don't really care if estimatedRowCount is 100% accurate, just big enough to know that this cursor is holding a lot of data.
Right now, I'm doing this:
// We multiply our rowcount
Int64 estimRowCount = 0;
try
{
estimRowCount = leftRowCount * rightRowCount;
}
catch (OverflowException)
{
// Ignore overflow exceptions
estimRowCount = Int64.MaxValue;
}
return estimRowCount;
Is there a better way to test for overflow operations so I don't have to do the try{}catch to guard?

This sounds like a good use case for the 'unchecked' keyword.
To use, simply wrap your assignment in an 'unchecked' block:
Int64 estimRowCount = 0;
unchecked
{
estimRowCount = leftRowCount * rightRowCount;
}
Then test to see if the result is negative - if it is, it overflowed:
if (estimRowCount > 0) estimRowCount = Int64.MaxValue;
You'll need to ensure in this case that neither leftRowCount nor rightRowCount can be negative, but given the context I don't think that'll occur.

if (Int64.MaxValue / leftRowCount <= rightRowCount)
{
estimRowCount = leftRowCount * rightRowCount
}
else
{
estimRowCount = Int64.MaxValue;
}
Not sure if I could explain myself without an editor.
But, I hope you get the idea.

Your solution seems quite reasonable. Is there something specific you want to optimize? Does that product cause the overflow condition so frequently that you're worried about the performance hit of the exception handling?
(Just simple food for thought, if leftRowCount and rightRowCount are Int32, not Int64, then your product cannot overflow your Int64 estimRowCount lvalue.)