# Error handling in Juno

**URL:** <https://discourse.julialang.org/t/error-handling-in-juno/13757>\
**Category:** Juno\
**Created:** [August 20, 2018, 9:58am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757 "2018-08-20T09:58:20Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![lhupe](https://avatars.discourse-cdn.com/v4/letter/l/9fc348/32.png) [@lhupe](https://discourse.julialang.org/u/lhupe)\
**Post date:** [August 20, 2018, 9:58am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/1 "2018-08-20T09:58:20Z")

</div>

I have recently noticed that error messages (the red pop-up thingies) in Juno are having some kind of problem.  
The MWE

```julia
throw(ErrorException("test"))

```

creates this error message

```julia
MethodError: no method matching -(::Nothing, ::Int64)
Closest candidates are:
  -(!Matched::Complex{Bool}, ::Real) at complex.jl:298
  -(!Matched::Missing, ::Number) at missing.jl:93
  -(!Matched::Base.CoreLogging.LogLevel, ::Integer) at logging.jl:107

```

This problem does not occur when I run the code in the REPL (both in a seperate terminal and in Juno).  
I use `julia-0.7.0` with all packages up to date.

**Edit:** as discussed below, this is not a Juno problem but an issue with the `julia` binaries provided by Arch Linux. I haven’t filed a bug report with the Arch repo yet, but if the problem doesn’t disappear in 1.0, I will.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [August 20, 2018, 10:34am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/2 "2018-08-20T10:34:07Z")

</div>

I can’t reproduce this problem with the latest release of Juno on Julia 1.0 (or Julia 0.7):  
 ![image](https://global.discourse-cdn.com/julialang/original/3X/c/d/cd387f34e0127e36cc24187e7553d2d23605c80b.png)

---

<div class="post-metadata">

**Author:** ![lhupe](https://avatars.discourse-cdn.com/v4/letter/l/9fc348/32.png) [@lhupe](https://discourse.julialang.org/u/lhupe)\
**Post date:** [August 20, 2018, 11:03am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/3 "2018-08-20T11:03:24Z")

</div>

Hmm. Weird. Do you know any configuration problem that could have caused  
this behaviour on my side?

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [August 20, 2018, 11:06am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/4 "2018-08-20T11:06:53Z")

</div>

No, but could you paste the contents of the `"julia-client"` portion of `~/.atom/config.cson` here? Also, what does `pkg> status` look like?

---

<div class="post-metadata">

**Author:** ![lhupe](https://avatars.discourse-cdn.com/v4/letter/l/9fc348/32.png) [@lhupe](https://discourse.julialang.org/u/lhupe)\
**Post date:** [August 20, 2018, 11:09am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/5 "2018-08-20T11:09:55Z")

</div>

```julia
  "julia-client":
    consoleOptions:
      terminal: "termite"
    firstBoot: false
    juliaOptions: {}
    uiOptions:
      enableMenu: true
      enableToolBar: true
      usePlotPane: false

```

and

```julia
    Status `~/.julia/environments/v0.7/Project.toml`
  [c52e3926] Atom v0.7.3
  [6e4b80f9] BenchmarkTools v0.4.0
  [53a63b46] CodeTools v0.6.1
  [31c24e10] Distributions v0.16.2
  [33d173f1] DocSeeker v0.2.0
  [4986ee89] DynamicalBilliards v2.1.0+ [`~/.julia/dev/DynamicalBilliards`]
  [7a1cc6ca] FFTW v0.2.4
  [5789e2e9] FileIO v1.0.1
  [cd3eb016] HTTP v0.6.14
  [7073ff75] IJulia v1.9.3
  [a98d9a8b] Interpolations v0.8.0
  [033835bb] JLD2 v0.1.0
  [e5e0dc1b] Juno v0.5.2
  [2fda8390] LsqFit v0.6.0+ [`~/.julia/dev/LsqFit`]
  [32113eaa] PkgBenchmark v0.1.1
  [438e738f] PyCall v1.18.0
  [d330b81b] PyPlot v2.6.0
  [295af30f] Revise v0.7.0
  [90137ffa] StaticArrays v0.8.3
  [2913bbd2] StatsBase v0.25.0
  [f218859d] TimeseriesPrediction v0.4.0
  [a2a6695c] TreeViews v0.3.0
  [9602ed7d] Unrolled v0.1.0

```

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [August 20, 2018, 11:16am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/6 "2018-08-20T11:16:00Z")

</div>

Hm, those look fine. Anything weird you did before trying to eval that code?

---

<div class="post-metadata">

**Author:** ![lhupe](https://avatars.discourse-cdn.com/v4/letter/l/9fc348/32.png) [@lhupe](https://discourse.julialang.org/u/lhupe)\
**Post date:** [August 20, 2018, 11:28am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/7 "2018-08-20T11:28:58Z")

</div>

I think I found the issue: until now I’ve been using the Arch Linux julia-0.7.0 package. Switching to the official binaries solved the problem.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [August 20, 2018, 11:30am UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/8 "2018-08-20T11:30:44Z")

</div>

Very weird. Glad it’s working for you now though.

---

<div class="post-metadata">

**Author:** ![lhupe](https://avatars.discourse-cdn.com/v4/letter/l/9fc348/32.png) [@lhupe](https://discourse.julialang.org/u/lhupe)\
**Post date:** [August 21, 2018, 1:17pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/9 "2018-08-21T13:17:35Z")

</div>

Update: still doesn’t work with the new julia 1.0 package ([`julia-2:1.0.0-1`](https://www.archlinux.org/packages/community/x86_64/julia/)) – I have filed a bug report with the Arch package maintainer, we’ll have to wait and see what happens.

---

<div class="post-metadata">

**Author:** ![NHDaly](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nhdaly/32/1413_2.png) [@NHDaly](https://discourse.julialang.org/u/NHDaly)\
**Post date:** [August 21, 2018, 1:46pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/10 "2018-08-21T13:46:42Z")

</div>

> [@lhupe](#):
>
> **Edit:** as discussed below, this is not a Juno problem but an issue with the `julia` binaries provided by Arch Linux. I haven’t filed a bug report with the Arch repo yet, but if the problem doesn’t disappear in 1.0, I will.

Huh, I’m not so sure. I’m on a Mac, using julia `v0.7.0 ` downloaded from the Julia website, and i’m seeing similar error messages.

I, like pfitzseb, don’t experience your problem with your test example (for me, `throw(ErrorException("test"))` correctly prints `> test` in red).

However, I do see the exact same error message as you when I experience a `StackOverflowException`:

Here’s my MWE:

```julia
foo() = foo() # > foo
foo() # causes "Julia Client – Internal Error" "MethodError: no method matching -(::Nothing, ::Int64)"

```

And here’s the full Atom error message:

```julia
Julia Client – Internal Error
MethodError: no method matching -(::Nothing, ::Int64)
Closest candidates are:
  -(!Matched::Complex{Bool}, ::Real) at complex.jl:298
  -(!Matched::Missing, ::Number) at missing.jl:93
  -(!Matched::Base.CoreLogging.LogLevel, ::Integer) at logging.jl:107
  ...
try_yieldto(::typeof(Base.ensure_rescheduled), ::Base.RefValue{Task}) at event.jl:196
wait() at event.jl:255
wait(::Condition) at event.jl:46
_wait(::Task) at task.jl:189
macro expansion at task.jl:205 [inlined]
(::getfield(Atom, Symbol("##107#112")))(::Dict{String,Any}) at eval.jl:82
handlemsg(::Dict{String,Any}, ::Dict{String,Any}) at comm.jl:168
(::getfield(Atom, Symbol("##14#17")){Array{Any,1}})() at task.jl:262

```

And in the REPL Console, I get the expected error:

```julia
julia> foo()
ERROR: StackOverflowError:

```

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [August 21, 2018, 2:03pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/11 "2018-08-21T14:03:52Z")

</div>

Ahaaa, that was very helpful. Bug is fixed with [this commit](https://github.com/JunoLab/Atom.jl/commit/49258cfb68cf316b7d4e0d5037f75bd610e7b5f2). Thanks, @NHDaly!

There still seems to be something wrong with the Arch executable considering that it throws weird errors (or stackoverflows in the wrong place).

---

<div class="post-metadata">

**Author:** ![NHDaly](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nhdaly/32/1413_2.png) [@NHDaly](https://discourse.julialang.org/u/NHDaly)\
**Post date:** [August 21, 2018, 2:05pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/12 "2018-08-21T14:05:30Z")

</div>

> [@pfitzseb](#):
>
> There still seems to be something wrong with the Arch executable considering that it throws weird errors (or stackoverflows in the wrong place).

Yeah that sounds right. +1 🙂

> [@pfitzseb](#):
>
> Ahaaa, that was very helpful. Bug is fixed with [this commit](https://github.com/JunoLab/Atom.jl/commit/49258cfb68cf316b7d4e0d5037f75bd610e7b5f2). Thanks, @NHDaly!

😄👍 So fast!! 😄 good stuff!! 👍👍👍

---

<div class="post-metadata">

**Author:** ![lhupe](https://avatars.discourse-cdn.com/v4/letter/l/9fc348/32.png) [@lhupe](https://discourse.julialang.org/u/lhupe)\
**Post date:** [August 21, 2018, 2:16pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/13 "2018-08-21T14:16:34Z")

</div>

> [@pfitzseb](#):
>
> There still seems to be something wrong with the Arch executable considering that it throws weird errors (or stackoverflows in the wrong place).

Using `Atom.jl` master, the only difference between Arch and julialang is now that the Arch version returns a much more verbose error message

![verbose_error](https://global.discourse-cdn.com/julialang/original/3X/9/1/91a5c24508c493270c69bb7c30a805a29a564695.png)

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [August 21, 2018, 2:25pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/14 "2018-08-21T14:25:34Z")

</div>

Hm, so the problem here is that the stacktrace _should_ contain a

```julia
in include_string at base\loading.jl:1002

```

entry as the second to last one.

Is there an easy way for me to install that version of Julia on Manjaro? AFAICT their package sources aren’t updated yet.

---

<div class="post-metadata">

**Author:** ![lhupe](https://avatars.discourse-cdn.com/v4/letter/l/9fc348/32.png) [@lhupe](https://discourse.julialang.org/u/lhupe)\
**Post date:** [August 21, 2018, 2:34pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/15 "2018-08-21T14:34:46Z")

</div>

Possibly using the [`unstable` branch](https://wiki.manjaro.org/index.php?title=Access_the_Unstable_Repositories)? I don’t know much about Manjaro, but according to their wiki the `unstable` repo is \< 3 days behind the Arch stable repos, so julia should already be at least at 0.7

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [August 21, 2018, 2:50pm UTC](https://discourse.julialang.org/t/error-handling-in-juno/13757/16 "2018-08-21T14:50:28Z")

</div>

Ok, so there’s something weird going on with stacktraces in that version of Julia:

 ![image](https://global.discourse-cdn.com/julialang/original/3X/e/2/e2235fad009c37a0e0aaa019435141b9043bf2a4.png)

Left is how it should look, right is what the Arch repo version gives. I suspect that happens because the directory structure is so radically different, but who knows.