One thing to consider could be the security risks of having separate errors, if a developer doesn't know they have to check for errors or forgets, what will happen when an error occurs?
What some languages gain for free with optional/nullable/joint types is a crash or exception when the returned value is treated as a valid value. (Though this might make it less apparent where the error occured)
Others like go force you to explicitly ignore the error if you don't want to care about it.
Then there's those that would throw an exception at error, which would tell you immediately where the error is. Though this might make the code uglier, or make the developer lazy and just do a catch all.
I think some languages with union types force you to program different execution paths for each possible type, but that might be more exclusive to languages with inferred typing.
That is a good point.
One thing I didn't point out is: another purpose of returning the empty User object, beyond satisfying the return type, is that it's a blank object that should be safe to use anywhere.
If you were to fetch an object and ignored the errors and tried to populate the view anyway, you would get blank values as the objects would have to be initialized with valid values such as empty strings, 0, or whatever is appropriate.
I think this addresses the concern, if I've understood you right.
Well, it depends on what the user object will be used for. If you only use it for displaying values then it should be fine.
If there's a chance the caller will be comparing a field to another, there may be unexpected behaviour if they don't check the error.
If the user plans on changing the object them storing it somewhere, then they may end up with lots of near-empty fields.
I must admit I haven't tried crystal, and I don't know the extent of what you're making, so I'm just listing issues that may occur with stuff that seems similar :-P
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One thing to consider could be the security risks of having separate errors, if a developer doesn't know they have to check for errors or forgets, what will happen when an error occurs?
What some languages gain for free with optional/nullable/joint types is a crash or exception when the returned value is treated as a valid value. (Though this might make it less apparent where the error occured)
Others like go force you to explicitly ignore the error if you don't want to care about it.
Then there's those that would throw an exception at error, which would tell you immediately where the error is. Though this might make the code uglier, or make the developer lazy and just do a catch all.
I think some languages with union types force you to program different execution paths for each possible type, but that might be more exclusive to languages with inferred typing.
That is a good point.
One thing I didn't point out is: another purpose of returning the empty User object, beyond satisfying the return type, is that it's a blank object that should be safe to use anywhere.
If you were to fetch an object and ignored the errors and tried to populate the view anyway, you would get blank values as the objects would have to be initialized with valid values such as empty strings, 0, or whatever is appropriate.
I think this addresses the concern, if I've understood you right.
Well, it depends on what the user object will be used for. If you only use it for displaying values then it should be fine.
If there's a chance the caller will be comparing a field to another, there may be unexpected behaviour if they don't check the error.
If the user plans on changing the object them storing it somewhere, then they may end up with lots of near-empty fields.
I must admit I haven't tried crystal, and I don't know the extent of what you're making, so I'm just listing issues that may occur with stuff that seems similar :-P