Skip to content

Return null values or throw exceptions in exercises? #360

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

Closed
robkeim opened this issue Aug 19, 2017 · 2 comments
Closed

Return null values or throw exceptions in exercises? #360

robkeim opened this issue Aug 19, 2017 · 2 comments

Comments

@robkeim
Copy link
Contributor

robkeim commented Aug 19, 2017

@ErikSchierboom @jpreese after seeing #353 and #359 I think we should agree on when we are going to have exercises return null values vs throw exceptions.

I'd like us to have some consistency and purpose in why we use the two. To simplify things we could move either all invalid input to null or to throw exceptions.

What do you guys think?

@jpreese
Copy link
Contributor

jpreese commented Aug 19, 2017

Hm, thats tough.

So my opinion is that the canonical-data should be the source of truth. Whatever is there, is what we render. I don't really think we should be making our own assumptions about what expected should be. Which means I believe we should just support both, and blame the canonical-data for using both.

An example of what I mean is take the phone-number canonical-data and the collatz-conjecture canonical-data.

phone-number explicitly states the expected return value should be null and the collatz-conjecture explicitly states it should return an error. I agree that they should probably be consistent, but I don't think thats our job. My vision is that our tests match the canonical data.

@robkeim
Copy link
Contributor Author

robkeim commented Aug 19, 2017

Ok, I had forgotten some exercises canonical data called for null while others were specifying "errors" which transition in C# as Exceptions. In that case I agree with you that we shouldn't be adding rules in our track and should follow what the canonical data specifies. That seems like a good policy to me!

@robkeim robkeim closed this as completed Aug 19, 2017
ErikSchierboom added a commit to ErikSchierboom/csharp that referenced this issue Jan 15, 2021
ErikSchierboom added a commit to ErikSchierboom/csharp that referenced this issue Jan 21, 2021
ErikSchierboom added a commit to ErikSchierboom/csharp that referenced this issue Jan 26, 2021
ErikSchierboom added a commit to ErikSchierboom/csharp that referenced this issue Jan 27, 2021
ErikSchierboom added a commit to ErikSchierboom/csharp that referenced this issue Jan 28, 2021
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

No branches or pull requests

2 participants