im currently working in a complete generic scenario in which i map a json as string to a dto class. That works fine with my function mapJsonToDto but im trying to make it more generic so that the developer who uses this function can also specify what exception to be thrown. So they can catch as they like. With this i avoid catching an IOException. Letting the function handle everything.
public class MapperUtils {
public <T extends Throwable> Object mapJsonToDto(Class<?> dtoClass, String jsonDto, T exceptionToThrow) throws IOException {
Object dto = null;
try {
dto = new ObjectMapper().readValue(jsonDto, dtoClass);
} catch (IOException e) {
throw new exceptionToThrow();
}
return dto;
}
}
I cannot understand how to pass an exception class instance to a function and throwing that specific as well.
Instead of passing the exception to throw (which would then have a completely wrong stack trace), I think you'd want a function that converts an exception from one type to another:
public <T extends Throwable, D> D mapJsonToDto(Class<D> dtoClass, String json, Function<IOException, T> exceptionMapper) throws T {
try {
return new ObjectMapper().readValue(json, dtoClass);
// if readValue doesn't do the casting right, try:
return dtoClass.cast(new ObjectMapper().readValue(json, dtoClass);
} catch (IOException e) {
throw exceptionMapper.apply(e);
}
}
And an example:
Person p = mapJsonToDto(Person.class, "{name: \"Joe\"}",
e -> new IllegalArgumentException("malformed JSON", e));
As a general rule, though, this seems like boneheaded design. If you find the IOException overly general, then you can't handwave the problem away by allowing the caller to provide a no doubt similarly overly general mapper. The only way out for a caller is to do a deep dive on the exception and write, I dunno, an if/elseif block with a ton of levels to it to try to ascertain the real problem e.g. via analysing the message, which is all sorts of ugly.
Either you don't care about that level of detail and you should therefore just stick with IOException (what point is there adding code and pointless layers of indirection?), or you do care and this isn't good enough; you'd want to design a better error system. Except, that's not your job, that'd be ObjectMapper.readValue's job. Which is why the IOException it throws should probably just be sent on unmolested.
Your example is nearly done.
I changed only the throws Type to T and throw the given exception.
public <T extends Throwable> Object mapJsonToDto(Class<?> dtoClass, String jsonDto, T exceptionToThrow) throws T {
Object dto = null;
try {
dto = new ObjectMapper().readValue(jsonDto, dtoClass);
} catch (IOException e) {
throw exceptionToThrow;
}
return dto;
}
Call: mapJsonToDto(String.class, "helo", new IllegalStateException());
Related
So I have these methods:
private List<ClientRepresentation> toClientRepresentation(String json) {
try {
return objectMapper.readValue(json, new TypeReference<List<ClientRepresentation>>() {
});
} catch (JsonProcessingException e) {
throw new RuntimeException("Could not parse json.");
}
}
private List<RoleRepresentation> toRoleRepresentation(String json) {
try {
return objectMapper.readValue(json, new TypeReference<List<RoleRepresentation>>() {
});
} catch (JsonProcessingException e) {
throw new RuntimeException("Could not parse json.");
}
}
private List<UserRepresentation> toUserRepresentation(String json) {
try {
return objectMapper.readValue(userJson, new TypeReference<List<UserRepresentation>>() {
});
} catch (JsonProcessingException e) {
throw new RuntimeException("Could not parse json.");
}
}
You can see these are similar... Would like to have one method for these... Something like this:
private List<T> toObjectsList(String json, Class classToConvert) {
try {
return objectMapper.readValue(json, new TypeReference<List<classToConvert>>() {
});
} catch (JsonProcessingException e) {
throw new RuntimeException("Could not parse json.");
}
}
Is it possible? How?
Thanks in advance.
Note first that Class<?> can be used to convey only type-parameter-less constructs. Thus, something like List<String> cannot be conveyed with it (only 'List' - any and all lists, unparameterized - that is the only thing Class can convey). If you ever want toObjectsList to return something like a List<Map<String, Object>> you are dead in the water on this: The entire setup fundamentally can't do it. So, first consider whether this is a good idea: You are handicapping yourself, that your toObjectsList method cannot ever return lists of type-argsed types. Presumably, if you're willing to document this and sign up to tacle such needs by not using toObjectsList and writing a custom readValue-based method instead, you're good to go.
Assuming you're on board with this restriction, the question boils down to: How does one construct an STT (Super-Type-Token, that TypeReference thing with the brackets after it) dynamically?
This should be doable, using the TypeFactory class.
For example, constructParametricType(List.class, List.class, classToConvert);.
We then need to address some other errors in your code:
That exception handling is deplorable. You're tossing away all the useful info, and replacing it with entirely useless information. Don't write a catch block that fails to address the issue, unless that catch block preserves all information. Also, by convention exception messages do not end in punctuation.
You are using a <T> in these methods, but you need to declare that T exists, first.
Class, itself, is parameterized.
This gets us to:
private <T> List<T> toObjectsList(String json, Class<T> classToConvert) {
JavaType typeTarget = TypeFactory.defaultInstance()
.constructParametricType(List.class, List.class, classToConvert);
try {
return objectMapper.readValue(json, typeTarget);
} catch (JsonProcessingException e) {
// pass the original exception along as cause, preserving info.
throw new RuntimeException("Could not parse json", e);
}
}
(You may have to cast to List<T>, but I don't think it'll be needed due to some dubious hackery on jackson's part).
I am having troubles while trying to refactor exception handling logic in an helper class.
My code uses a repository which accesses a database and might throw the custom exception RepositoryException. If such exception is thrown by the repository, I want my code to catch it and set an error label in the graphical user interface (view):
... // more code
try {
existingCourse = repository.findByTitle(course.getTitle()); // <- throws RepositoryException
} catch (RepositoryException e) {
view.showError(e.getMessage(), course);
return;
}
... // some more code
The point is that this code is repeated several times and I would prefer to have it refactored in an helper class.
This is what I came up to after some experiments:
A custom FunctionalInterface called ThrowingSupplier, which represent the code that throws the exception.
A TransactionManager helper class, with a catcher methods that accepts a ThrowingSupplier
This is the related code (BaseEntity is just a base class for entities in my domain, as you might guess):
// ThrowingSupplier.java
#FunctionalInterface
public interface ThrowingSupplier<T extends BaseEntity> {
T get() throws RepositoryException;
}
/* ------------------------------------------------------ */
// ExceptionManager.java
public final class ExceptionManager<T extends BaseEntity> {
private T result;
private String exceptionMessage;
ExceptionManager() {
}
public boolean catcher(ThrowingSupplier<T> supplier) {
try {
clearResult();
clearExceptionMessage();
result = supplier.get();
return true;
} catch (RepositoryException e) {
exceptionMessage = e.getMessage();
}
return false;
}
// public getters and 'clearers' for attributes
...
}
And this is how I am using this now:
...
em = new ExceptionManager();
... // more code
if (!em.catcher(() -> repository.findByTitle(course.getTitle()))) {
view.showError(em.getExceptionMessage(), course);
return;
}
existingCourse = em.getResult();
... // some more code
Now it seems to me that this does not give any advantages with respect to using directly the try catch in every repository invocation. This is mainly because I need both the return value of the repository method and a way to tell the caller if the repository call has been successful. As a variation I tried to add the showError call inside catcher, but then I must pass view and entity in every invocation of catcher, which I do not like very much as it makes the code less readable.
Is there another way to accomplish this in an elegant manner or it is better to leave the try catch in every call to the repository? Also, what is the standard way to deal with this problem?
Let's say we have such a simple parser:
public class ResourceManager {
private final static Logger LOG = Logger.getLogger(ResourceManager.class);
public Museum parseJSONFile(String filePath) /*throws IOException ???? */ {
Museum museum = null;
try {
ObjectMapper objectMapper = new ObjectMapper();
museum = objectMapper.readValue(new File(filePath), Museum.class);
} catch(IOException e) {
LOG.error(e);
}
return museum;
}
}
Should the exception be caught in method or in the calling code? Which variant is better?
Parser can't do anything with exception, so that's an exceptional situation for a parser and it can't produce any expectable result. Someone from the outside should handle it.
In particular, it should not return null as it will result in bunch of null-checks in calling code (which you can easily forget to put, or due to the lack of documentation on your implementation I just don't know whether I have to check for null without seeing the code). This is one of the problems that exceptions in Java were intended to solve. By declaring checked-exception in method signature, you're enforcing users of your parser to deal with fact that value might not come.
I have been searching online and researching in some books, but the examples given are limited and I still have some doubts in user-defined exception.
Using the following codes as an example:
//Conventional way of writing user-defined exception
class IdException extends Exception
{
public IdException(String s)
{
super(s);
}
}
class Product
{
String id = new String();
public Product(String _id) throws IdException
{
id = _id;
//Check format of id
if (id.length() < 5)
throw(new IdException(_id));
}
}
It seems that the conventional way of writing a user-defined exception is almost always the same. In the constructor of the user-defined exception, we always call super(msg). This triggers a question in me: If most exceptions are implemented this way, what difference are there between all these exceptions?
For example, I can have multiple user-defined exceptions, but all seems to do the same thing without any differences. (There is no implementation in these exceptions, what makes them work?)
Example:
class IdException extends Exception
{
public IdException(String s)
{
super(s);
}
}
class NameException extends Exception
{
public NameException(String s)
{
super(s);
}
}
class ItemException extends Exception
{
public ItemException(String s)
{
super(s);
}
}
QUE: So shouldn't we (for example) implement the checking of id inside the exception class? If not all exception classes just seem to do the same thing (or not doing anything).
Example of implementing the check in an Exception:
class IdException extends Exception {
public IdException(String s)
{
super(s);
//Can we either place the if-statements here to check format of id ?
}
//Or here ?
}
Ideally you should not implement your business logic inside Exception. Exception tells information about exceptional behaviour, And in Custom Exception you can customise that information.
Find the best practice to write Custom Exception.
We have so many Exceptions already defined in java. All do the same thing : to notify user about the problem in code.
Now suppose we have only one Exception, then How we can what error occurs when the exception is thrown. After all, name matters a lot.
To take your example Exceptions, I would create a more elaborate message by formatting the data provided:
public IdException(String id, String detail) {
super(String.format("The id \"%s\" is invalid: %s", id, detail));
}
throw new IdException(_id, "Id too short.");
This way there is no real logic in the IdException class other than providing the given value (id) and a detail message together in the e.getMessage() String so debugging and logging is easy to read and the code itself is also straightforward:
There is something wrong with the Id _id, namely it is too short. Thus we throw it back at the caller.
Also, when you throw different types of Exceptions in a code, it allows caller code to handle each Exception type differently:
try {
getItem(id, name);
} catch (IdException ex) {
fail(ex.getMessage()); // "The Id is bogus, I don't know what you want from me."
} catch (NameException ex) {
warn(ex.getMessage()); // "The name doesn't match the Id, but here's the Item for that Id anyways"
} catch (ItemException ex) {
fail("Duh! I reported to the dev, something happened");
emailToAdmin(ex.getMessage()); // "The Item has some inconsistent data in the DB"
}
class MyException extends Exception{
int x;
MyException(int y) {
x=y;
}
public String toString(){
return ("Exception Number = "+x) ;
}
}
public class JavaException{
public static void main(String args[]){
try{
throw new MyException(45);
}
catch(MyException e){
System.out.println(e) ;
}
}
}
output: Exception Number = 45
I have a question related to String.format in JAVA.
My HibernateDao Class is responsible for persisting entities and will throw an exception in case I have any constrain violation. The message contains a %s and will be used as a format in the upper layers, as I should be worried about types in this layer, thus can't identify what object I could not persist.
public Entity persistEntity(Entity entity) {
if (entity == null || StringUtils.isBlank(entity.getId()))
throw new InternalError(CANNOT_INSERT_NULL_ENTITY);
try {
getHibernateTemplate().save(entity);
} catch (DataAccessException e) {
if (e.getCause() instanceof ConstraintViolationException)
throw new HibernateDaoException("%s could not be persisted. Constraint violation.");
throw new HibernateDaoException(e);
}
return entity;
}
And then in my DaoHelper Class I will catch this exception and throw a new one, with a formatted message.
//Correct Code
public Entity create(Entity object) throws MyException {
try {
return this.hibernateDao.persistEntity(object);
} catch (HibernateDaoException he) {
String format = he.getMessage();
throw new MyException(String.format(format,object.getClass().getSimpleName()));
}
}
My question is, why I cannot directly call the he.getMessage() in my String.format method?? And must use a 'tmp' variable instead... It just won't substitute the %s from the string.
//What I wished to do, but I cant.
public Entity create(Entity object) throws MyException {
try {
return this.hibernateDao.persistEntity(object);
} catch (HibernateDaoException he) {
throw new MyException(String.format(he.getMessage(),object.getClass().getSimpleName()));
}
}
Thx in advance.
This should be closed, as the intended behavior is working. As #Kal and #highlycaffeinated commented, calling the getMessage() directly does work, something must have happened with my build and did not update correctly. However the messages do appear correctly now.
Thanks for the quick answers :)