The one place for your designs
Upload and view the latest designs for this issue. Consistent and easy to find, so everyone is up to date.
eg:
class InvalidMethod extends ApiException
{
private $message = "This method is not allowed";
}
Sentry should not catch these errors and the API should cleanly report the error message.
class InsufficientBalance extends UserException
{
private $message = "You do not have enough tokens to fulfill this transaction";
}
Sentry should log, and the API may return a generic message.
class DatabaseException extends ApplicationException
{
private $message = "The database couldn't be communicated with";
}
Sentry should log, and the API should return a traceable error code.
class Exception extends \Exception
{
private $message = "There was unknown error";
}
We want to be sure it is you, please confirm you are not a robot.
changed the description 2 times within 1 minute
I recently used InvalidParameterException when the user select a date older than 3 months for a scheduled activity. In my understanding, this is not the correct use of exceptions, since technically, it feel just like a sort of flow control. The same occurs to me, for instance, with InsufficientBalance extends UserException
. Is this really an exception or just a scenario where the endpoint should inform something to the user that the operation couldn't be completed? For me, it resembles more to a normal endpoint response.
I think @juanmsolaro has hit the nail on the head there.
I tend to think of exceptions in terms of HTTP status codes.
500, something went wrong, raise an alarm in sentry because something is broken. 400, user/data/logic error, most of the 400s are situational errors and these are exceptions that should probably be reported to the user in a nice manner.
Upload and view the latest designs for this issue. Consistent and easy to find, so everyone is up to date.