Skip to content
This repository has been archived by the owner on Jun 5, 2021. It is now read-only.

Avoid panic #4

Closed
backkem opened this issue Apr 30, 2018 · 2 comments
Closed

Avoid panic #4

backkem opened this issue Apr 30, 2018 · 2 comments

Comments

@backkem
Copy link
Contributor

backkem commented Apr 30, 2018

There are quite some uses of the panic keyword, mostly in the default case of switch statements. Is there a reason for this? It seems strange to 'blow up' the program in case of unexpected input. Users of the library would have to recover methods that may panic. In addition, gracefully handling unexpected input seems rather important in a P2P protocol. Maybe we should just return errors in these cases? Finally, It would also make testing easier.

@ernado
Copy link
Collaborator

ernado commented May 1, 2018

Hi @backkem, thank you for the response. Don't worry, no unexpected input should cause the panic.
I'm using panic to ensure internal consistency in code, putting it in unreachable code branches.
They can be called only as a cause of some nasty and obvious bug that also means that the program is incorrect and output could be incorrect too. The standard library is also using panics in such way.

Do you have an example of input that causes panic?

@backkem
Copy link
Contributor Author

backkem commented May 1, 2018

Ah, you are right. Thanks for clarifying.

@backkem backkem closed this as completed May 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants