Migrate errors to static enums

[jedel1043]

Our current design for TemporalError is essentially a mirror of ECMAScript's error types:

temporal/src/error.rs

Lines 39 to 43 in 345ad54

	#[derive(Debug, Clone, PartialEq)]
	pub struct TemporalError {
	kind: ErrorKind,
	msg: Box<str>,
	}

This works well for engines that have thousands of errors, with each one having a custom message. However, I don't think we need to do that for temporal_rs, and a more rusty approach will be better suited for this. thiserror sounds ideal for this (moreso because it recently added support for no_std).

[jasonwilliams]

This works well for engines that have thousands of errors, with each one having a custom message. However, I don't think we need to do that for temporal_rs

I think we do pass through error messages up from the underlying parsers and things, would this design still work with that?

Also, what advantage does thiserror bring over using static enums?

[jedel1043]

I think we do pass through error messages up from the underlying parsers and things, would this design still work with that?

Yep, because the underlying ixdtf uses this design for errors :)

https://docs.rs/ixdtf/latest/ixdtf/enum.ParserError.html

Also, what advantage does thiserror bring over using static enums?

It removes the boilerplate of having to wrap errors generated by inner calls, implement the Error trait and implement the Display trait. Though, we could do it manually if we see that it's not that hard to maintain.

[nekevss]

Yeah, the initial design was primarily focused on compatibility with Boa's error type. But it probably is not the most optimal error type for a general purpose library.

[Manishearth]

Thought:

struct TemporalError {
   kind: ErrorKind,
   msg: 
}

#[derive(Display)
enum TemporalErrorMsg {
    /// Invalid time
    InvalidTime,
    ...
    Custom(Box<str>),
}

And over time we migrate everyone over from Custom, eventually removing it.

One thing to consider: Some errors might wish to be parametrized. This will make things harder for FFI, but it might still be manageable if the number of parameters is limited and they are all themselves enums.

[nekevss]

My initial thought was something along the lines of:

pub enum TemporalError {
    Range(RangeError),
    Type(TypeError),
    ...
}

We could start with the custom on TypeError and RangeError, and then slowly build them out?

Maybe that's a bit too much in this case