Error type consistency

[pmcq]

Should standardize the error_type field between langpack implementations. I think it's more useful to be the "exception type" (whatever that means in the given language) if possible.

https://github.com/algorithmiaio/langpacks/blob/master/python/template/bin/pipe.py#L70
https://github.com/algorithmiaio/langpacks/blob/master/ruby/template/bin/pipe.rb#L28

[Argoday]

Looks like error_type is no longer documented on http://docs.algorithmia.com/#input-output , the original purpose of using an enum like AlgorithmError (like in the python example) was to enable clients to implement retry strategies according to the received value inside the error_type field (aka: was there a potentially transient error in the algorithmia infrastructure? or was there an error on the inside of the algorithm container). This can only reasonably be accomplished via a script-readable mechanism like enum or status code.

If there is a different mechanism for detecting retry-ability client-side or if such retry strategy hasn't been found to be useful then this field can be co-opted for a human-readable "exception type".

[anowell]

Correction @Argoday: long ago we had discussed what you described with error_type, but it was never implemented (outside of common message passing). For langpacks we added the field to minimally surface algorithm errors from errors that occur within langserver so that we could finally distinguish the errors in internal logs (i.e api_log), but to this day error_type is not exposed through the public API.

1. I would very much like to expose error_type - for the reasons @Argoday outlined
2. I agree @pmcq that the runners should capture the exception type and use that as the error_type (with something like AlgorithmError as a fallback default if we don't have meaningful type, e.g. String) while still reserving one or more error_type values for Algorithmia system errors. The caveat is that a error_type name collisions are possible. Today I could write a ruby algorithm that throws an exception with class SystemError, and it would wind up in the wrong error metrics. So perhaps we need yet-another-field to distinguish this. :-/

[pmcq]

Yeah I think there's a need of some discussion on what the right approach is (before creating issue I had a feeling it'd be yet-another-field) but we've talked about error codes as an option as well. Anyway, just didn't want to lose track of this.

[Argoday]

my mistake - I forgot we only had error_type in the internal messages