try without catch not documented

[ArchRobison]

While reviewing #9316, I learned that try...end does not require a catch or finally. But I can't find this construct documented in the manual section about exception handling. Did I miss something, or do we need to describe it in the manual? The semantics are surprising for programmers coming from a C++ background, so I think it deserves notice.

The semantics seem to be that tryexprend returns the value of expr, unless an exception occurs, in which case it returns false.

[IainNZ]

Should probably return a Nullable

[JeffBezanson]

Oops. I must have intended to return nothing, which is the standard value of an empty block like begin end or if false end.

[StefanKarpinski]

I was going to say that nothing seems like the consistent thing to return here. I don't recall the timeline here but it's possible that you implemented try before we had nothing.

[kmsquire]

The current behavior is used, e.g., in RandomMatrices.jl, to test for the ability to import another package.

Cc: @jiahao

[jiahao]

@kmsquire I think the issue here is a little different. In my code I wrote HAVE_X = try using X; true catch false end which explicitly returns false when an exception is thrown. The specific behavior that is questionable is that try error() end == false, which is as if every try block had a default catch; return false clause.

[ArchRobison]

Returning nothing seems much more coherent. The false had me puzzled.

[kmsquire]

@jiahao, I read that code and don't know how I missed that! Sorry for the noise.

[MikeInnes]

It occurs to me that we should add a way to document keywords like try via the repl help mode. I'll put this in when I get the chance.

[IainNZ]

It turns out a few packages relied on this behaviour, e.g. JSON:
https://github.com/JuliaLang/JSON.jl/blob/2fdfc2999593f287bea377b1604dd1302a75b12a/src/Parser.jl#L5-L8

[JeffBezanson]

Yes, this should definitely not be backported since it is breaking.

[kmsquire]

I think I wrote that code, so that probably should have been my example
above. :-)

On Sunday, December 14, 2014, Jeff Bezanson [email protected]
wrote:

Yes, this should definitely not be backported since it is breaking.

—
Reply to this email directly or view it on GitHub
#9320 (comment).

[tkelman]

Oh right, the behavior changed here. Still worth documenting 0.3's behavior on release-0.3. Would doing git diff 76c991d7~ 76c991d7 | sed -e 's/nothing/false/g' | git apply look okay to everyone?

[tkelman]

There were no objections so I backported the modified version (returns false on release-0.3) in a1b156f