PSP Development/Basic Error Handling

The amount of potentially breaking errors on PSP skyrockets as program complexity develops. C is a language that enables the develop functional programs on performance constraint systems. The PSP is a power device, comparable to the power a PS2 has, where the PS Vita trumps the power of the PS2. Being a console, it is finicky when it comes to undefined behavior, mis-allocated data, incorrect pointer math, and null pointers more severe than a computer. The problem comes from the console being embedded to run a certain way, without the ability for user homebrew development. There is a proprietary system designed specifically as a productivity and debugging environment.

NOTE All future articles will use the functions below.

Error Handling Strategy

Runtime errors are the easiest to handle. A runtime error occurs when the system operates on data whose results return incorrect or act on invalid data (page/seg faults). It is up to the programmer to write the program correctly so that runtime errors are non-existent, or handled without the system being in-able to continue. If managed to ever get the pleasure of writing a physical UMD disc, the programmer is inept with errors like reading in cases of the player removing the disc, inability to read, dropping the psp, and more. In applications that use UMDs, an example error could be the user removes the UMD while it is being read from. The program needs to alert the user the operation was cancelled and retreat back to a functional state.

C Compiler Errors

In Python and Java, a programmer will be familiar with the try catch statement. However, C has its own style of handling things. Error Handling in C documents a few error checking strategies. It is important to understand more than the advice given in the article. Under #PSPDEV Errors, undefined can be almost directly a synonym for C errors. C errors tend to crash completely on runtime. A method for scoping out the problems should be utilized. The difference between C errors and PSPDEV errors would come from correctness in using the library against the more syntactical or memory related issues. The try-catch systems added to other languages are a product of the commonality of errors and a Runtime Error Handling strategy to circumvent them changing broken productivity to productivity.

PSPDEV Errors

Runtime errors have three different modes: expected, unexpected, and undefined. An expected error could be when the system checks if a file is present to load into the system. The system would return a status. An unexpected error could occur when data in the file is corrupt - the program can't use this file. The system couldn't immediately detect this without potentially crashing. These two errors mean the program can not continue with the requested action. Instead of continuing on with incorrect data, possibly running into null pointers and misaligned data, a solution is stopping the operation and alerting the user. An undefined error is writing code that is syntactically correct and theoretically correct, but crashes. Freeing allocated memory and setting the pointer to 0 and attempting to use the variable pointer may cause the program to crash, for example. The difference between unexpected errors and undefined errors is undefined errors do not get to the stage where an unexpected error can occur.

Expected and Unexpected Errors

With the PSPDEV in specific, a lot of functions return an int, which represents an error at a certain value. Some programs display the errors to the user through graphical libraries. Inside main.c is a functional place to put single helper functions which take in the common parameters, and displays them to the user. This article talks about handling errors in a clean way, given a crash has occurred. The reason for this goes back to the inane, impossibility of making a 'one size fits all' error checking function, while also enabling the ability to circumvent them so the program can function still. The try-catch statement is born because of this problem, with the ability to check for listen to the expected or unexpected errors and the program has instructions on going about working around them. C doesn't have a try-catch statement, so this article aims at a more creative way to handle errors.

How the function below works is it revolves around being on the main thread anywhere called in the main() function. Since debug mode is commonly operated on the main thread, which keeps the program alive and updating, it would make sense to write directly to the end of everything printed on a new line, print the error, and sleep the main thread indefinitely to crash. This allows the ability to read an error message. A callback system can be implemented instead of sleeping the thread (to handle the error like try-catch) by supplying the method with a function, which inherits relevant, common parameters for error handling. It is wise to ensure vblank for the ability to call this function anywhere. The function below is best used for both Expected and Unexpected errors.

main.c

void crash(int error, const char* crasher, const char* message) {
	sceDisplayWaitVblankStart();
	printf("Error (%d) : %s\n", error, crasher);
	printf("%s\n", message);
	sceKernelSleepThread();
}

Undefined Errors

The PSP's biggest let down is crashing without output. A tool needs be implemented to enable the rooting out of the possible undefined errors. In addition to this, it is also needs to be a fake forced crash. Because a line of code can crash, outputting text before it and hanging the thread will result in no crash and text to be shown. However, if the attempt is made to print after the line of code that crashes, the thread will not hang and no text will appear. Using this logic, one can shift a print-stall function around the suspected lines of code to understand which line of code causes the crashing. However, the fix is not the simple, for the previous lines could inflict the cause of the line which crashes.

The code below is a spin off of the expected and unexpected errors function code, except there is less to it. There is little to no logical output to output that will be of help. However, if necessary, parameters could be added, but this adds the complexity of filling them in. Instead, when the crashed line is found, printing the variables associated will likely save time and effort. Doing this will further help identify the problem, too. Doing printf for the error not found, entails checking variables values whom are unrelated to the crash.

main.c

void test_crash() {
	sceDisplayWaitVblankStart();
	printf("No crash occured.");
	sceKernelSleepThread();
}

Advanced Error Handling

Using pspDebug, a function to act as a error handler can be installed. With the error handler, comes output from the PSP. This helps debug what went on. Future articles MAY use this under certain circumstances, like problematic examples. This is like a try catch clause with stderr - when an error happens, data is collected and a problem is stated.

Working Example

• expected/unexpected
  • main.c : http://pastebin.com/Lw3n2WnE
• undefined
  • main.c testcase 1 : http://pastebin.com/eWvZR5Pd
  • main.c testcase 2 : http://pastebin.com/DzUH4X3j