{"action":"opened","issue":{"url":"https://api.github.com/repos/Beagle-PSE/Beagle/issues/285","labels_url":"https://api.github.com/repos/Beagle-PSE/Beagle/issues/285/labels{/name}","comments_url":"https://api.github.com/repos/Beagle-PSE/Beagle/issues/285/comments","events_url":"https://api.github.com/repos/Beagle-PSE/Beagle/issues/285/events","html_url":"https://github.com/Beagle-PSE/Beagle/issues/285","id":122847632,"number":285,"title":"How defensive do we program?","user":{"login":"jGleitz","id":4305652,"avatar_url":"https://avatars.githubusercontent.com/u/4305652?v=3","gravatar_id":"","url":"https://api.github.com/users/jGleitz","html_url":"https://github.com/jGleitz","followers_url":"https://api.github.com/users/jGleitz/followers","following_url":"https://api.github.com/users/jGleitz/following{/other_user}","gists_url":"https://api.github.com/users/jGleitz/gists{/gist_id}","starred_url":"https://api.github.com/users/jGleitz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jGleitz/subscriptions","organizations_url":"https://api.github.com/users/jGleitz/orgs","repos_url":"https://api.github.com/users/jGleitz/repos","events_url":"https://api.github.com/users/jGleitz/events{/privacy}","received_events_url":"https://api.github.com/users/jGleitz/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Beagle-PSE/Beagle/labels/discussion","name":"discussion","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-12-17T23:46:48Z","updated_at":"2015-12-17T23:46:48Z","closed_at":null,"body":"“defensive programming” describes a way programming giving users of an API detailed error messages when they use an API wrong, for instance (but not limited to) by checking input arguments. This might lead to less bugs. \r\n\r\nnon-defensive programming puts the method’s contract above anything. If the programmer breaks the contract by providing bad input, it’s “his fault” and the API has undefined behaviour¹.\r\n\r\nFor example, a method may return useable, but false values. Defensive programming would check the input arguments and throw an exception and prevent the programmer from continuing with false values. \r\n\r\nI think we should agree on an consistent style. Please note that defensive programming requires more unit tests!\r\n\r\n¹ as some of us learned in ICPC, undefined behaviour may include erasing your hard drive ;)"}}