# Common error: providing an Integer when a Float is expected

**URL:** <https://discourse.julialang.org/t/common-error-providing-an-integer-when-a-float-is-expected/17786>\
**Category:** Optimization (Mathematical)\
**Created:** [November 20, 2018, 5:28pm UTC](https://discourse.julialang.org/t/common-error-providing-an-integer-when-a-float-is-expected/17786 "2018-11-20T17:28:36Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![miles.lubin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/miles.lubin/32/279_2.png) [@miles.lubin](https://discourse.julialang.org/u/miles.lubin)\
**Post date:** [November 20, 2018, 6:03pm UTC](https://discourse.julialang.org/t/common-error-providing-an-integer-when-a-float-is-expected/17786/3 "2018-11-20T18:03:13Z")

</div>

This actually speaks to an issue that is deserves more visibility in the Julia world. We’ve made a significant correction to JuMP development practices to implement what I call the “`MethodError` principle”: [Style Guide · JuMP](http://www.juliaopt.org/JuMP.jl/dev/style/#User-facing-MethodError-1). Basically, error messages at library boundaries should explain to users what _they did wrong_ and not which internal assumptions were violated deep in the code. For the specific case of `MethodError`s this implies that “_A user should see a `MethodError` only for methods that they called directly._”

This is a goal that’s not always possible with generic code; however, there are small changes that could go a long way once we recognize this as a priority. I don’t have time to write an essay on this right now, but maybe I will later.

---

_[View the full topic](https://discourse.julialang.org/t/common-error-providing-an-integer-when-a-float-is-expected/17786)._