Error handling in Juno


#1

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

throw(ErrorException("test"))

creates this error message

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.


#2

I can’t reproduce this problem with the latest release of Juno on Julia 1.0 (or Julia 0.7):
image


#3

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


#4

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


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

and

    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

#6

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


#7

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.


#8

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


#9

Update: still doesn’t work with the new julia 1.0 package (julia-2:1.0.0-1) – I have filed a bug report with the Arch package maintainer, we’ll have to wait and see what happens.


#10

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:

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

And here’s the full Atom error message:

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> foo()
ERROR: StackOverflowError:


#11

Ahaaa, that was very helpful. Bug is fixed with this commit. 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).


#12

Yeah that sounds right. +1 :slight_smile:

:smile::+1: So fast!! :smile: good stuff!! :+1::+1::+1:


#13

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


#14

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

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.


#15

Possibly using the unstable branch? 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


#16

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

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.