6.12.1: Error Handling
Posted: Thu Mar 31, 2011 8:38 pm
This is the first in a series of posts about some of the new features that will be released in Ren'Py 6.12.1 - which I hope to make a pre-release of relatively soon. The goal of this, and the next few releases, is to make life easier for game-makers.
I'll start off with the new error handling feature. Previously, a Ren'Py exception was reported by the game crashing, and then (depending on platform) an error message coming up on the screen. While easy to implement, this behavior didn't have much to recommend it - it made fixing the bugs more painful then they need be.
Here's a screenshot of the error handling in 6.12.1:
When an exception occurs that Ren'Py is capable of catching, this screen pops up. It displays a small, censored traceback at the top of the screen, showing the bits of Ren'Py code that were involved in the stack trace. When an editor is configured, you can click on the line numbers (in blue) to launch that file in a text editor.
At the bottom of the screen, there are a number of options. (The precise options shown vary based on when the error occurs.)
Rollback Choosing this option causes Ren'Py to rollback to the previous screen. For the end user, this is probably the best possible choice, as it puts him into a position to save the game.
Ignore It's often possible to try to determine what the next statement is early in the execution of a statement - for example, when the say statement runs, it will always go through to the next statement. When this is possible, the Ignore button will let the user skip through to the next statement. This can lead to errors - such as when the user Ignores a failing python block - but it may be better than nothing, especially if the game is no longer supported by the creator.
Reload is only available when config.developer is set. This reloads the game - similar to shift+R reload. This is probably what developers will use the most, as it supports a fix-the-bug-and-continue style of debugging.
Open Traceback opens the traceback in a text editor. This is what we have now - but since the new code shows the traceback on screen, it's only necessary to click this if you want to send the traceback to the maker.
Quit quits Ren'Py. Do not pass go - etc.
I figured I'd show this a bit early so that people can get used to it, and make suggestions. I'm considering adding a plug-in system that allows user code to add buttons to this screen - but the problem is that we're in a really weird state here, and I'm not sure how well it would work.
This also shows the new Ren'Py "House Style" that will be used for Ren'Py specific screens - exception handling, display troubleshooting options, the style inspector, and eventually things like the new launcher. These screens (and the styles they use) should be considered part of Ren'Py, that only advanced or very unlucky users would ever see - they aren't meant to be customized by the game-maker.
I'll start off with the new error handling feature. Previously, a Ren'Py exception was reported by the game crashing, and then (depending on platform) an error message coming up on the screen. While easy to implement, this behavior didn't have much to recommend it - it made fixing the bugs more painful then they need be.
Here's a screenshot of the error handling in 6.12.1:
When an exception occurs that Ren'Py is capable of catching, this screen pops up. It displays a small, censored traceback at the top of the screen, showing the bits of Ren'Py code that were involved in the stack trace. When an editor is configured, you can click on the line numbers (in blue) to launch that file in a text editor.
At the bottom of the screen, there are a number of options. (The precise options shown vary based on when the error occurs.)
Rollback Choosing this option causes Ren'Py to rollback to the previous screen. For the end user, this is probably the best possible choice, as it puts him into a position to save the game.
Ignore It's often possible to try to determine what the next statement is early in the execution of a statement - for example, when the say statement runs, it will always go through to the next statement. When this is possible, the Ignore button will let the user skip through to the next statement. This can lead to errors - such as when the user Ignores a failing python block - but it may be better than nothing, especially if the game is no longer supported by the creator.
Reload is only available when config.developer is set. This reloads the game - similar to shift+R reload. This is probably what developers will use the most, as it supports a fix-the-bug-and-continue style of debugging.
Open Traceback opens the traceback in a text editor. This is what we have now - but since the new code shows the traceback on screen, it's only necessary to click this if you want to send the traceback to the maker.
Quit quits Ren'Py. Do not pass go - etc.
I figured I'd show this a bit early so that people can get used to it, and make suggestions. I'm considering adding a plug-in system that allows user code to add buttons to this screen - but the problem is that we're in a really weird state here, and I'm not sure how well it would work.
This also shows the new Ren'Py "House Style" that will be used for Ren'Py specific screens - exception handling, display troubleshooting options, the style inspector, and eventually things like the new launcher. These screens (and the styles they use) should be considered part of Ren'Py, that only advanced or very unlucky users would ever see - they aren't meant to be customized by the game-maker.