Replies: 8 comments 4 replies
-
A "resource does not exist" error makes sense at the Ballerina language level, independent of HTTP. This feels like a common case. One could handle this by having langlib defining a distinct error type for this, which HTTP could map into 404. Apart from this, what are the common cases where application wants to return a non-500 error? |
Beta Was this translation helpful? Give feedback.
-
They have: |
Beta Was this translation helpful? Give feedback.
-
@jclark @shafreenAnfar |
Beta Was this translation helpful? Give feedback.
-
Discussed in high level chat: |
Beta Was this translation helpful? Give feedback.
-
Following idea was proposed for edge cases by James (names are my own): // in lang.error
public type NotFound distinct error; type UserNotFound distinct error:NotFound;
function userFromId(string id) returns User|UserNotFound {
...
} http library will check if the returned error is a subtype of |
Beta Was this translation helpful? Give feedback.
-
We discussed having another error similar to above for |
Beta Was this translation helpful? Give feedback.
-
I see one anti-pattern in this: https://ballerina.io/learn/by-example/http-error-handling/ which is to define an object type with a single method. This feels like a Java-ism stemming from OO thinking plus absence of a function type. I would say that it makes better use of the language to use a function type instead (in this case from a error to an HTTP response). |
Beta Was this translation helpful? Give feedback.
-
Users mentioned that when the api are called by websites, they need to present user friendly error messages for display purposes. |
Beta Was this translation helpful? Give feedback.
-
Goal
Following scenario has come up during the internal apps project. We need to determine a general best practice for where to create non-500 error in an HTTP service.
Issue
Above solution produces 500 when the user doesn't exist, but let's say the programmer intends to return HTTP 404. Issue gets worse if there are multiple levels of function calls before we get to
usersFromId
. How can one achieve this?I think the root issue is the inability to use the
check
keyword with HTTP errors.Proposed solution 1
Create a function that maps internal errors to http errors. Wrap returns in resource functions with a call to the function.
But this solution negatively impacts the diagram generation, as well as understandability.
Proposed solution 2
Same as above solution, but move the logic in the function to an interceptor. This cleans up the resource function.
But this adds an unnecessary layer to the http logic.
Proposed solution 3
Create http errors at deeper levels.
Ugly since
usersFromId
knows about HTTP, and can't use thecheck
keyword.Solution 4
This seems to me the simplest, even if it complicates resources a little bit.
Beta Was this translation helpful? Give feedback.
All reactions