Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception catching #511

Open
pitr-ch opened this issue Feb 15, 2016 · 2 comments
Open

Exception catching #511

pitr-ch opened this issue Feb 15, 2016 · 2 comments
Assignees
Labels
enhancement Adding features, adding tests, improving documentation. medium-priority Should be done soon.

Comments

@pitr-ch
Copy link
Member

pitr-ch commented Feb 15, 2016

C-R should unify on what exceptions to catch. Discussed in #507

@pitr-ch pitr-ch added the enhancement Adding features, adding tests, improving documentation. label Feb 15, 2016
@pitr-ch pitr-ch added this to the 2.0.0 Release milestone Feb 15, 2016
@pitr-ch
Copy link
Member Author

pitr-ch commented Feb 15, 2016

The Ruby exception hierarchy puts the exceptions from which we are picking on the same level so I think it's valid to put together a list of exceptions which should be caught because otherwise they would break the abstraction or would be silently ignored which is highly undesirable.

The list of exceptions was not put together carefully though, and it should be discussed further.

The hierarchy:

  Exception
    NoMemoryError
    ScriptError
      LoadError
      NotImplementedError
      SyntaxError
    SecurityError
    SignalException
      Interrupt
    StandardError
      # ...
    SystemExit
    SystemStackError
    fatal

I think that only unrecoverable exceptions (fatal, NoMemoryError) and SystemExit should not be caught, rest makes sense to report to the user as a failed future. SignalException afaik can be ignored since it's raised only on main thread.

@jdantonio
Copy link
Member

"puts the exceptions from which we are picking on the same level..."

Yes, so treating them all identically is reasonable.

"only unrecoverable exceptions (fatal, NoMemoryError)..."

This is a subjective choice. It is impossible for us to know a priori that NoMemoryError is unrecoverable, so grouping it with fatal is an arbitrary choice. It is impossible in Ruby to rescue fatal but it is possible to rescue all the others. If the Ruby core team considered NoMemoryError to be unrecoverable they would have just used fatal. But they didn't and we should be consistent with their choices.

@pitr-ch pitr-ch self-assigned this Jul 6, 2018
@pitr-ch pitr-ch added the medium-priority Should be done soon. label Jul 6, 2018
@pitr-ch pitr-ch removed this from the 2.0.0 milestone Jul 6, 2018
@pitr-ch pitr-ch added this to Interesting features in Hackathon Aug 24, 2019
@pitr-ch pitr-ch moved this from Interesting features to Important in Hackathon Aug 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adding features, adding tests, improving documentation. medium-priority Should be done soon.
Projects
Hackathon
Important
Development

No branches or pull requests

2 participants