Treating Async Errors as value, or How We Learned to Stop Worrying and Love the crashes
Published
6/12/2024


Alright the title is probably bit exaggerating, since nobody in their right frame of mind would love crashes in their software, but I am trying to drive a bigger point home.



When we started the development of OrangeGas we decided to use Solid JS and Strapi in backend, We used Neverthrow. and we were in for a treat, we could be sure about the application, we knew when it failed and we could log those failure and work towards a more stable version.


As Orange Gas project grew, we realised the need for server-side rendering (SSR) because our application was client side rendered and we wanted to have more reach from search engines, we could achieve that with SSR, So we decided to migrate the existing SolidJS codebase to SolidStart, built on top of SolidJS, offered a seamless way to add SSR capabilities. We could leverage the power of server-side rendering while still enjoying the benefits of SolidJS's reactive paradigm.


As we migrated the project from SolidJS to SolidStart, which adds server-side rendering and other advanced features, we discovered that the existing error handling library, Neverthrow., was no longer compatible due to SolidStart's isomorphic nature. To overcome this hurdle, we decided to write a simpler version of Neverthrow and called it "err-as-value", to work seamlessly with SolidStart's reactive primitives.





By returning Result values from functions, I could handle success and error cases using the ok and err functions, respectively. This approach made the code more expressive and forced me to handle errors at the call site, preventing them from being overlooked.


Embracing the concept of "Errors as Value" has been a game-changer in my journey as a software developer. It has brought clarity, consistency, and simplicity to my codebase, making it easier to understand and maintain. By treating errors as normal values and propagating them through the application in a functional and declarative manner, I have found a way to handle errors effectively without compromising the readability and maintainability of the code. This approach has not only improved the robustness of my applications but has also made the development process more enjoyable and less error-prone. I believe that adopting "Errors as Value" can benefit developers working with various frameworks and libraries, as it promotes a more thoughtful and structured approach to error handling.


This is first blog of technical series where our staff write about the technical challenges and pattern, check the whole series at https://orangegas.co/public/16/collection/technical-thoughts-1718172742576?includeDrafts=false