Should we add Errno::ESRCH?

Help & Support
1

Check following code.

Process.signal Signal::TERM, 1000000

There is a great chance you will get following error message:

But the POSIX kill documents the “search” connotation:

[ESRCH]
No process or process group can be found corresponding to that specified by pid.

For this case, Ruby use Errno::ESRCH, Python use errno.ESRCH, I try to CORRET this in my port_ruby_to_crystal, but i really consider i do somethings wrong.

I should’t replace Error::ESRCH to RuntimeError, instead, I think Crystal should support Error::ESRCH, like this:

begin
  Process.signal Signal::TERM, 1000000
rescue Error::ESRCH
end

Check the ruby Process::kill document too.

1 Like
2

You can access the underlying errno value via RuntimeError#os_error:

begin
  Process.signal Signal::TERM, 1000000
rescue exc : RuntimeError
  e.os_error # => ESRCH
end
1 Like
3

If this is intentional (raise RuntimeError all all OS level error), I am fine, just curious, when rescue RuntimeError, if will shadow some unexpected exception.

4

Yes, there’s not a specific error class for every error condition. That would be just too complex of a hierarchy.
So we usually group common error types into classes.

In the rescue handler you get a chance to inspect the exception. If you don’t intend to handle that specific error at this place, you can re-raise it:

begin
  Process.signal Signal::TERM, 1000000
rescue exc : RuntimeError
  if e.os_error == ESRCH
    # ignore ESRCH
  else
    raise exc
  end
end
2 Likes