@grosser can you try running make std_spec instead of using bin/crystal? I think running make deps would fix the error, but it's recommended to use make when developing the crystal compiler.

I prefer the behavior that raise inside a rescue block would reraise the current exception. IThis is similar to many other languages. Calling raise without a current exception being handled would be a wrong usage, and we could raise some exception type for this. (Calling throw; in C++ when there is no current exception simply aborts the current program)

@lbguilherme well I really don't think that this is enough trouble to warrant a language feature:

begin
  raise "ex"
rescue ex
  raise ex if ...
end

@lbguilherme +1, see #3181. Unfortunately, it'd require messing with the global state which is a no-no, especially after 0.19, where globals are gone for good.

yeah did not think about re-raise ... raise without argument just working would be confusing / lead people to believe that it re-raised ... so ideally it should fail and say "Raising without argument is not supported, please pass a message or the exception you want to re-raise" ... not sure if that is easy to add ... closing this for now since I think it would make things worse.

One approach would be to take the Ruby route and allow raises without arguments both inside and outside exception handlers, but with different behaviours - raise outside simply raises, whereas inside it will default to the exception being handled.

You only need local state for that - noone would expect raise in a method called from the exception handler to magically know where it was called from.