The usual way to avoid problems with your production site is to try out everything first on a dev or staging site, and then push it to production after it is tested. There are two main problems with php in blocks: one is that block data is stored in the database. If you push the database from dev to production, you will lose new content on your live site -- no good. The solution to this problem is to use the features module to export your database configuration to your code files, which allows you to push your config-in-code from dev to live & then re-import on the live site.
The other problem with putting php in blocks, though, is that it opens up a security hole in your site, as anyone who has the right to configure blocks can now run code on your server. This means that your site is one guessed password away from compromise at all times. It is therefore better to write your blocks in code using a custom Drupal module rather than put php in the database.
If you do have a site with malformed code in a block, you can disable the block using the drush block-disable command from the drush_extras project.