try without catch should not catch

[oxinabox]

This is a breaking change,
but I feel like I should point it out now while 0.7 is still alpha,
as there is a chance it can be fixed before 1.0

Right now: if you have a try block that has neither a catch nor a finally,
it is the same as a try block with a catch.
But if you have a try block without a catch and with a finally it does not catch anything.

My gut tells me that without a catch nothing should be caught.
and also that adding an empty finally block should never change behaviour.

Right now the tryblock comes in 4 forms:

try-catch-finally:

Catches (what I expected)

julia> try
               error("NOOO")
       catch

       finally

       end

julia> 

try-catch

Catches (what I expected)

julia> try
               error("NOOO")
       catch

       end

julia>

try-finally

Does Not Catch (what I expected)

julia> try
               error("NOOO")
       finally

       end
ERROR: NOOO
Stacktrace:
 [1] anonymous at ./<missing>:?

julia> 

try

Catches (Not what I expected)

julia> try
               error("NOOO")
       end

julia>

---

This caught me off-guard today,
because I had some code that I had added a catch block to, for debugging purposes.
I was using it as a big of a hack dump out some extra state to the screen so I could find what was wrong with my code.

When I was done debugging, I commented out the catch block,
because I didn't want to catch things anymore.

Many weeks later (today) I come back to the code, and I do something kinda silly for other debugging reasons (printing an undefined variable)
and I am sitting here wondering first "Why am i not getting the expected output", and then once I found my mistake "Why is my program not erroring out?"

[martinholters]

IIUC correctly, wrapping a block in try ... end without catch or finally should be equivalent to just the wrapped block? Is there then any need for it? Should we just disallow it?

[oxinabox]

IIUC correctly, wrapping a block in try ... end without catch or finally should be equivalent to just the wrapped block?

Yes, that is what I am saying.

Should we just disallow it?

Could do:

• Java disallows it
• C# disallows it as a specific named error
• Python can't even parse it and treats it as incomplete statement (which I guess it is)

So just plain making it a syntax error would be reasonable

[JeffBezanson]

Yes, I think we can disallow it.

[Ken-B]

FWIW, I like the try ... end syntax. It allows me to try some code over many datasets without having to worry about data quality up front and get a feel for the results. In production code I would use catch (at least for logging) but for exploration the try ... end is convenient.
(It's also easier for a one-liner).
In @oxinabox 's debugging story, I would rather comment out the try than just the catch, but it seems we have different expectations from a try keyword.

[StefanKarpinski]

julia> @eval macro $(:try)(ex)
           quote
               try $(esc(ex))
               catch
               end
           end
       end
@try (macro with 1 method)

julia> @try error("BOO")