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

Reconsider the use of @assert #81

Open
akabla opened this issue Jun 4, 2020 · 2 comments
Open

Reconsider the use of @assert #81

akabla opened this issue Jun 4, 2020 · 2 comments
Labels
enhancement New feature or request invalid This doesn't seem right
Milestone

Comments

@akabla
Copy link
Member

akabla commented Jun 4, 2020

Are we using @Assert properly?
the doc suggests that this should be for debugging rather than validating inputs:
https://docs.julialang.org/en/v1/base/base/#Base.@assert

It may be best to move towards the 'error' function or throwing proper exceptions that could be caught by the program.
https://scls.gitbooks.io/ljthw/content/_chapters/11-ex8.html

@moustachio-belvedere
Copy link
Member

moustachio-belvedere commented Jun 5, 2020

Sounds good to me. Yes I think things weren't quite as clear in 0.6 so I got into the wrong habit! The nice thing about assert is (was) that we could have a very clear message about what was wrong, in plain english. So if we want to replace then throwing a custom ErrorException with a clear message, or defining our own clear custom exception is probably the way to go.

Edit: Also, related to the above docs on @assert, we should consider doing testing and benchmarking at higher optimisation levels to see how much of a difference that makes to us (could be significant for example in computation of Mittag-Leffler). If the -O3 flag is beneficial, we should document it. I did play around with it a bit in older versions but I don't remember it having much effect then though.

@akabla
Copy link
Member Author

akabla commented Jun 5, 2020

I agree that we should set our own Exception class just for clarity. To get a message out, the 'error' function should also do the job though.

@akabla akabla added this to the 1.0.0 milestone Jun 5, 2020
@akabla akabla added the enhancement New feature or request label Jun 5, 2020
@akabla akabla added the invalid This doesn't seem right label Apr 7, 2021
akabla added a commit that referenced this issue Sep 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

2 participants