Endpoints uses ServiceException to easily return the right Http Codes. Developers can extend it and create their own exceptions.
I would like to suggest a "RuntimeServiceException" for the following reasons:
Since ServiceExceptions are checked we need to cascade the handling over the code, usually polluting the code with "throws ServiceException" or similar.
Usually ServiceExceptions does not requires special handling other than return the proper HTTP Codes. They could be Runtime Exceptions. Even though exception is runtime the developers could handle them with try / catch blocks.
The criticism about Java checked exceptions overuse is known. Old frameworks and APIs used to have checked exceptions everywhere. After some years the frameworks has started to adopt RuntimeExceptions more widely. E.g.: javax.persistence.EntityNotFoundException from JPA is Runtime.
Endpoints uses ServiceException to easily return the right Http Codes. Developers can extend it and create their own exceptions.
I would like to suggest a "RuntimeServiceException" for the following reasons:
Since ServiceExceptions are checked we need to cascade the handling over the code, usually polluting the code with "throws ServiceException" or similar.
Usually ServiceExceptions does not requires special handling other than return the proper HTTP Codes. They could be Runtime Exceptions. Even though exception is runtime the developers could handle them with try / catch blocks.
The criticism about Java checked exceptions overuse is known. Old frameworks and APIs used to have checked exceptions everywhere. After some years the frameworks has started to adopt RuntimeExceptions more widely. E.g.: javax.persistence.EntityNotFoundException from JPA is Runtime.
best regards!!