# What should I call an internal casting function that may fail

(Almost) all numbers in my program are parsed and treated as complex numbers. There is one corner cases, that specifically needs an integer. Unfortunately my programming languages does not allow to compare integers to complex numbers so I needed to come up with the following code:

``````function_name(Complex c)
if c has imaginary part != 0
throw exception
if ( integer(real(c)) - real(c) ) != 0
throw exception
return integer(real(c))
``````

I'm stuck on how to call this function. If I call it something like `complex_to_int` I think it hides the fact, that it fails on non integer complex numbers. If the complex number is real, then I (or other people) might expect this function to work like a normal cast from a floating point value to an integer (i.e. the decimal places are just cut off).

My question is:
-Is there a good name to call this function

Or, at the risk of the question being too subjective

-Should I split this function in two and actually have a real casting function (that just ignores potential imaginary parts and cuts of decimal places) and write a function that checks if the complex number fulfills my criteria before casting it?

• The integerness of this particular complex number is certainly not an accident. Why don't you store it as an integer from the start so that it is obvious to the compiler and to the reader of your code that some value is indeed an integer and not a complex number that happens to have neither imaginary part nor fractional real part? Commented Feb 17, 2020 at 13:02
• Because it comes from user input and by default all user inputs are treated as complex numbers. It's part of a scientific calculator. The only case where integers are required are if you want to use matrix-indices in your query. Commented Feb 17, 2020 at 13:10

You can take inspiration from .NET's TryParse series of methods.

In .NET, a "TryParse" method attempts to parse the parameter it receives, and returns either true or false - true if the conversion was successful, false if it was not.

The parsed number is then returned using an out parameter.

You can use a similar naming scheme for your fuction. "TryConvertToInteger" makes it very clear that this is an attempt, and nothing else - it may very well halt and catch fire.

Another option you have is to do a more... naive casting, and call your method "GetIntegerPart" or similar:

• Do not check if the number is an integer.
• Do not check if the number has an imaginary part.
• Instead, just take out the real part, round it up to the nearest integer, and be done with it.

ex.:

``````2-2i -> 2
3.4+i -> 3
3.6-i -> 4
``````

Then it is up to the caller to decide if they need to check the imaginary part or not, or if they need the extra precision.

• Regarding on the "returns either true or false" part of the answer: Consider twice if you want to do that or use an exception - because one day, you will `TryParse` and forget to check the return value. And silent failures are the worst thing that can happen to you (better your application crashes & burns - telling you that something went wrong - than it keeps working with oh-so-slightly wrong values, which are a pain to debug and may cause things to crash & burn... in the real world) Commented Feb 17, 2020 at 13:16
• After reading this it seems so obvious to just add a "try" to the function name. Thanks! I also prefer things do go down guns blazing, so I'll stick to the exception approach. Commented Feb 17, 2020 at 13:18
• @CharonX I agree. Personally, I don't like much the approach of returning a true/false thing, but I think the naming convention is on-point. Commented Feb 17, 2020 at 14:08
• Re not checking the return value of a `TryParse` - if you're working in C#, it's pretty easy to write an analyzer in Roslyn that will turn forgetting to check into an error. Commented Feb 17, 2020 at 15:54
• Well, aside from returning true or false, and throwing an exception... we could use an option type. And depending on the language/platform, that might be the idiomatic way of doing things. For C# `TryX` returning `bool` is idiomatic. And yes, Roslyn can help with that. I wish we didn't have to add a reference (or roll our own) to have an option type... However, since we are talking of an integer, in .NET `int?` would be an alternative. Commented Feb 17, 2020 at 16:02