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

Python API: log and swallow all exceptions #549

Closed
wants to merge 10 commits into from

Conversation

emilk
Copy link
Member

@emilk emilk commented Dec 13, 2022

Instead of throwing errors, the logging SDK will now log errors, including call stack. This means the users code will continue to run, just with broken rerun logging.

Checklist

  • I have read and agree to Contributor Guide and the Code of Conduct
  • I've included a screenshot or gif (if applicable)
  • I've added a line to CHANGELOG.md (if this is a big enough change to warrant it)

# Add this to ALL user-facing functions!
# TODO(emilk): add "strict" mode where we do pass on the exceptions
def log_exceptions(func: Callable[..., RT]) -> Callable[..., Optional[RT]]:
def wrapper_log_exceptions(*args: Any, **kwargs: Any) -> Optional[RT]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this interfere with type hinting or are the tools smart enough to trace this through?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It interferes, I think. The public signature will now have Any as the parameter types.

Apparently things are better in Python 3.10: https://stackoverflow.com/a/68290080

But considering how bad type checking is in Python anyway, I rather have this than leaking exceptions

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also beginning to think that we should consider being much more loose with our typing anyway. We really don't want our types getting in the way of making Rerun easy to use. The main point for us really is documentation

@jleibs
Copy link
Member

jleibs commented Dec 13, 2022

This pretty much looks exactly like what I would expect.

@emilk emilk marked this pull request as ready for review December 14, 2022 09:30
@jleibs
Copy link
Member

jleibs commented Dec 16, 2022

With this fix I continue to get type checking functionality in vs-code in python3.10. Would be great to get someone with an older python to confirm this doesn't break anything.

@emilk
Copy link
Member Author

emilk commented Dec 16, 2022

No, it doesn't work for me 😭 :

Screen Shot 2022-12-16 at 10 22 26

Same on main:

Screen Shot 2022-12-16 at 14 49 37

@jleibs
Copy link
Member

jleibs commented Dec 16, 2022

But does it crash?

I think typing_extensions makes it valid python… but doesn’t actually include the full functionality.

@emilk
Copy link
Member Author

emilk commented Dec 16, 2022

But does it crash?

I think typing_extensions makes it valid python… but doesn’t actually include the full functionality.

It runs fine, but the type hinting is broken which is quite sad

RT = TypeVar("RT") # return type


def log_exceptions(func: Callable[PS, RT]) -> Callable[PS, Optional[RT]]:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can try what @jondo2010 did here: #1186 (comment)

@emilk emilk marked this pull request as draft February 14, 2023 10:34
@emilk
Copy link
Member Author

emilk commented Mar 2, 2023

I'm gonna give this another go

@emilk
Copy link
Member Author

emilk commented Mar 2, 2023

Replaced by #1477

@emilk emilk closed this Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants