Simple: no es posible en Java (a menos que cambie el tipo de retorno a Objeto, pero eso es una práctica muy mala). Pero bueno, "no recomendado" sería el mejor término.

Por supuesto, podrías hacer algo como esto.

 class RequestResult { static enum Result { PASS, FAIL }; private Whatever dataForPass; private SomethingElse dataForFail; Whatever get(){ return get((dataForFail)->throw new RequestError(dataForFail)); } Whatever get(ErrorHandler handler){ if(dataForFail != null){ return handler.handle(dataForFail); } return dataForPass; } } interface ErrorHandler{ Whatever handle(SomethingElse dataForFail) throws RequestError; } class RequestError extends RuntimeException{ SomethingElse data; RequestError(SomethingElse data){ this.data=data; } }

luego puede dejar que RequestResult maneje cómo obtener los datos de Whatever que sea / SomethingElse más, por ejemplo:

 Whatever data = result.get((dataForFail) -> ...); //or throws a RequestError if `SomethingElse` presented. Whatever data = result.get();

y luego crear tal objeto; y dependiendo del resultado real, configure ese objeto con los datos requeridos. Al hacerlo, el tipo de devolución de ese método podría ser RequestResult; y podría usarlo para aprobar y fallar solicitudes. Pero esa no es la "práctica estándar".

En cambio: solo devuelve algo cuando pasa el método. De lo contrario, lanza una excepción apropiada, que contiene la información que la persona que llama necesita para mostrar un mensaje de error útil.

En otras palabras: debes separar claramente el camino "feliz" y el "infeliz". En Java, lo hace lanzando excepciones cuando las cosas van realmente mal.

La afirmación es que esto no es posible en Java: aunque literalmente no es posible, existen bibliotecas para hacer esto de manera segura, inspiradas en la misma interfaz segura que proviene de otros lenguajes de programación.

Uno de los más prometedores en mi navegación rápida fue el lambda de @palatable , que define la idea como:

 public abstract class Either<L, R> { private Either () {} // how you make these public static <L, R> Either<L, R> left(L l) { return new Left<>(l); } public static <L, R> Either<L, R> right(R r) { return new Right<>(r); } // how to use these public abstract <V> V match(Function<? super L, ? extends V> leftFn, Function<? super R, ? extends V> rightFn); /* ~ some convenience methods to have a common interface to handle these things ~ */ // the actual classes private static final class Left<L, R> extends Either<L, R> { private final L l; private Left(L l) { this.l = l; } @Override public <V> V match(Function<? super L, ? extends V> leftFn, Function<? super R, ? extends V> rightFn) { return leftFn.apply(l); } /* some other functions to get .equals() working right etc. */ } // same for Right but with "R" swapped for "L" }

Una vez que defina esto una vez, puede tener el tipo de devolución real que desea como Either <String, ResponseBody> y puede return Either.left("hey, it's a string") o bien return Either.right(response.getBody()) y luego puede manejar ambos tipos como datos.

Como muchos otros han notado, otra forma de manejar un tipo de Either <String, x> es como una excepción que rompe el flujo lógico normal de la aplicación; incluso puede definir una excepción más general. Sin embargo, recuerde que esto omitirá cualquier lógica común que desee hacer para ambos. Debe decidir si hay alguna lógica de aplicación compartida entre lo que desea hacer con el cuerpo de la respuesta y la String de error, o si desea tener este tipo de instrucción goto que salta directamente a un bloque catch designado. Esas respuestas pueden ser diferentes para diferentes aplicaciones.

Supongo que esto en su pregunta debería ser un servicio JAX-RS REST.

Así que solo quiero mostrar cuál es mi manera de hacer las cosas, no digo que sea correcta ni perfecta.

En un servicio REST devuelvo un objeto como este

 class APIResponse { private Object content = null; private Integer code = null; private String message = null; ... getter, setter and what else }

La clase APIResponse es el objeto común devuelto por los puntos finales REST:

 public Response questionIdGet(String id, SecurityContext securityContext) { StatusCode sc; try { sc = new APIResponse().content(surveyBuilder.getQuestionById(id)).code(200); return Response.ok() .entity(sc) .build(); } catch (Exception e) { return Response.status(500) .entity(new APIResponse().content(e).code(200).message(e.getMessage())) .build(); } }

De esta forma, sus clientes REST reciben un objeto común donde saben dónde encontrar el contenido { "content" : object } y comprueban si es válido o no { "status" : 200, "message" : "error..." } .