Hi!
When you're writing a library in gleam. Are there conventions for how you report errors to the user? For example, lets say I'm parsing a string and encounter an unexpected character. Should I return an error string like "Unexpected character (row=12, col=34): d" or should I return a custom type like UnexpectedCharacter(12, 34, "d"). Returning a string feels like I've taken away information from the user, forcing them to parse the string if they want to use the error programmatically, however returning a custom type feel like I'm introducing a leaky abstraction. Which way would be according to gleam conventions?
#What are the gleam conventions around error propagation?
sharp canopy
What are the gleam conventions around error propagation?
woven spoke
I try to think about the value that the user could get. Do you foresee them ever needing to know (programmatically) where the unexpected character was?
If there's only one error situation, I often use Nil as the error type like the stdlib does. It's more convenient to handle and works if the user doesn't need to dig into the error or detect one error from the other.
sharp canopy
So assuming that the row, col, and char are important to the user. Should i return a custom type then? Are string errors something to refrain from?
woven spoke
if they are important to the user, then they should have easy access to them. I'm not sure how the latter is more a leaky abstraction than the former
sharp canopy
@woven spoke I'd say the latter is leaky since it exposes the user to a custom type. The former only exposes the user to strings.
twilit oxide
I think it depends on what kind of importance they have, like if having the row/col/char could be used further downstream to recover from the error somehow then a custom type to make retrieving those easier is a good idea, but if the program is in a hopeless state and the only thing that can be done is to fail and report why, then a formatted string is easier to understand on the console