You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 5, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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?
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.
The text was updated successfully, but these errors were encountered: