Refactor executes errors

[lkelly93]

Added types_errors.go

• Added 4 new error types
  • UnsupportedLanguageError
  • CompilationError
  • TimeLimitExceededError
  • Runtime Error
• These errors will be used through out the package to differentiate between different error types.

executable.go

• Slightly changed NewExecutable logic so we didn't have to create an extra variable just to return it.
• Changed NewExecutable so it returns and UnsupportedLanguageError instead of a generic error.
• Changed Run's return type to (string, error) so it can return the new errors
  • Small changes through out Run() so it can return RuntimeErrors and TimeLimitExceeededErrors
  • @joshua-sterner do you want to combine RuntimeErrors and TimeLimitExceededErrors? I could see them as being one thing. What is easier from the server's perspective?

Test Files

• Changed test files to check to make sure they are getting the proper error type.

All runner_XXXX.go files

• Changed their fileCreationFunction's return time to also return an error so we can check for compilation errors.
  • Currently none of the languages we support need to be compiled but this is just setting up for future languages.

runner_java.go

• Renamed some variables for easier readability.

types.go

• Changed signature of the Run() method in the Executable interface
• Changed return type for fileCreationFunctions from (string, string) -> (string, string, error)

@joshua-sterner I am going to let you approve this merge because these changes are going to be mostly implemented by the server package. Let me know if you have any questions.

[lkelly93]

@joshua-sterner The build failed because I changed the return type for Run() but is passing all my local tests. Let me see if I can fix that really quick. I don't have the server package pulled over into this branch yet.

[joshua-sterner]

@joshua-sterner do you want to combine RuntimeErrors and TimeLimitExceededErrors? I could see them as being one thing. What is easier from the server's perspective?

I think it makes sense for these to be separate, as we might want slightly different behavior in the frontend in response to these two error types.