There wouldn’t BE an exception if the system was properly handling this in the first place. I.e. validating the input.
Id much rather have an exception than a silent bug. It would stop the items from being sold, inform the user there is a problem, and logging would capture something went wrong. The user doesn’t lose their items, and the application owner knows something didn’t work right.
Maybe for your use case defaulting to max would be the better option, but you can’t honestly say that is the behavior that should be used by default. It’s up to the application’s logic to handle these cases, i.e. the game itself.
Yes, silent bugs are bad. @IEatReturnValues4 Who’s to say I want the max value? Maybe I want the min value? Maybe I a completely different value. Silently setting to max makes that impossible, and dangerous.
The rule that the amount of gold should max out on some value is clearly a domain-specific property.
Thus it needs to be implement it in the application domain and not the language should be oriented for that very specific use case.
When the addition operator raises, you can easily respond to that in you application code. An example would be this:
struct LimitedMoney
def initialize(@value = 0)
end
def +(amount)
new_value = @value + amount rescue Int32::MAX
LimitedMoney.new(new_value)
end
end
class Klass
property gold = LimitedMoney.new
end
p = Klass.new
p.gold += Int32::MAX
p.gold += 1
pp p.gold
If the addition operator would just work in the way you expect, it would maybe fit your use case (as long as the application requirements don’t change) but it’s clearly not generically useable.
First of all, this is the way overflows are handled in several languages. Crystal is not unique in this aspect. There are 3 ways to handle overflows, none of which are prefect, but only one of which is actually safe. The first way is that you wrap, this is what C does and it leads to unexpected behavior in many cases. The second is that you do what you’re requesting and just have a hard stopping point at the max value, this also can lead to unexpected behavior. And the third way is exactly how the Crystal devs have decided to do it, which is throwing an exception. No unexpected behavior, and exceptions are catchable, meaning if it overflows you can always catch the exception and set your integer to the max value yourself.
The second thing you need to realize is that this is a free and open source project in which hundreds of people have donated countless hours of development time and resources. It is impossible to make everyone happy, and so devs have to do what they see as being best for the language itself. Some decisions may end up requiring a few more lines of code in the end, but not everything should be about one-liners. They are not important.
Gotta say, you’ve not made a great first impression on many members of the community. Learn to listen more and talk less. Best advice I can give you.
Defaulting to a max value would destroy my data if it overflowed and is the wrong approach for reliability. If my code has an instruction to do something i expect it to work, not silently discard my instructions.
Try this:
struct Int32
def maybe_add(n)
self + n
rescue OverflowError
MAX
end
end
Many languages wrap around when overflowing. Does any language have the behavior he wants?
I think the request is extremely odd and is useless for anything except a video game counter. If I was storing a warehouse inventory counter I’d prefer an exception rather than losing track of how many items I have.
@watzon Blacksmoke said I’m a bad apple. Better tell him to be respectful to me as well then. Or, are you playing favorites? Just because you don’t agree with someone else and have differing viewpoints than yours?
You’ve been told several times how to do what you want, and why your idea is terrible from a language design perspective. You just don’t know how to listen. There is nothing more to be said. Case closed. Move on.