I like to think about exceptions like this: “Exceptions are only to communicate with developers(or more generally maintainers of the application) NOT users” Do you think that’s a good rule?
I see exceptions more for unexpected errors that we can't possible can recover from like hardware failures that prevent the application from functioning. All errors that we can possibly recover from by retrying or letting the user decide are better treated like part of the result and communicated in the function signature.
Result types are just preparing you to eventually distinguish between HTTP status codes for whenever your application gains a web API. You might as well start with them and avoid exceptions altogether. Also, every time you think you could use null as a value, just stop. You're probably wrong. If it's a stand-in for an empty string or zero, just use those values to begin with. You can avoid a lot of null checks that way. Unexpected nulls are always exceptional. The only exception is when you have to interface with someone else's code that doesn't follow this rule, forcing you to handle null like a definite value.
![[ENGSUB] UNPRODUCTIVE DAY ใช้ชีวิต (เปื่อยๆ) ด้วยกัน 1 วัน! | OUROAD CLOSEFRiEND SS2 EP.9](http://i.ytimg.com/vi/pyYKZ3kra9w/mqdefault.jpg)
I like to think about exceptions like this: “Exceptions are only to communicate with developers(or more generally maintainers of the application) NOT users” Do you think that’s a good rule?
@MaNgAnlmE I think this is a quite good guideline 👍
I see exceptions more for unexpected errors that we can't possible can recover from like hardware failures that prevent the application from functioning. All errors that we can possibly recover from by retrying or letting the user decide are better treated like part of the result and communicated in the function signature.
Result types are just preparing you to eventually distinguish between HTTP status codes for whenever your application gains a web API. You might as well start with them and avoid exceptions altogether.
Also, every time you think you could use null as a value, just stop. You're probably wrong. If it's a stand-in for an empty string or zero, just use those values to begin with. You can avoid a lot of null checks that way. Unexpected nulls are always exceptional. The only exception is when you have to interface with someone else's code that doesn't follow this rule, forcing you to handle null like a definite value.
Looking at languages like F# and Rust I think result types have much more potential