Sandbox without absolving Throwables

[yisraelU]

adds an orDie method to remove typed errors from Route and routes where the error is <:< Throwable

[codecov-commenter]

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (badb929) 64.37% compared to head (8a20142) 64.33%.

Files	Patch %	Lines
zio-http/src/main/scala/zio/http/Route.scala	0.00%	4 Missing ⚠️
zio-http/src/main/scala/zio/http/Routes.scala	0.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2574      +/-   ##
==========================================
- Coverage   64.37%   64.33%   -0.04%     
==========================================
  Files         140      140              
  Lines        8315     8320       +5     
  Branches     1504     1515      +11     
==========================================
  Hits         5353     5353              
- Misses       2962     2967       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[987Nabil]

I am not sure, this is a good idea. It seems confusing for me. The contract of zio-http error handling is, that we always return a response. One might not like the default behavior of sandbox, but there is iirc an even more hidden way, that I am not sure a user can always influence, if there is a defect.

Can you elaborate on your use case and why the already existing ways to handle errors don't fit?

[yisraelU]

Hi @987Nabil , sure. I totally get that this is not the standard usecase.
These methods can be of benefit when interoping with libraries that I don't control and don't expose enough capabilities.
The idea is that many libraries rely on Exception throwing as a means of passing information. I want my throwables to be interpreted to Responses , however I do not want to use the default Response.fromCause(_) , nor do I have the local context to provide such logic
Essentially what I am currently doing is a
handleError(throw _).toHttpApp

and allowing the library to convert the throwable to a Response

[jdegoes]

@yisraelU I think that @adamgfraser recently added a method that may help you out here.

[987Nabil]

@yisraelU did you build this changes locally and check that they do want you want? Because seeing the code, I am not sure they do. I think we might do some defact to response logic deep in the guts of zio-http.

That said, I am not sure, that map error throw is not good enough for your use case and we should rather keep a misleading or misbehaving orDie away from the user. Btw I can't test around my self, I am just checking from the phone 😉

[yisraelU]

@jdegoes nice. yes thats great

[yisraelU]

@987Nabil No I didnt test locally.