Сериализация нулевых значений с помощью jackson
Я пытаюсь сериализовать через jackson некоторые поля, которые могут быть нулевыми, с помощью специального сериализатора. Читая онлайн, кажется, что Джексон должен написать «нулевую» строку, и если я хочу другой вывод, я должен следовать этому примеру с официального гитхаба
Проблема в том, что я получаю NullPointerException вместо «нулевой» строки.
Это происходит как с JsonGenerator.writeNumberField, так и с JsonGenerator.writeStringField.
Чтобы написать пустую строку, я должен управлять исключением, или я что-то упускаю?
Это трассировка стека:
com.fasterxml.jackson.databind.JsonMappingException: [no message for java.lang.NullPointerException]
at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider._wrapAsIOE(DefaultSerializerProvider.java:509) ~[jackson-databind-2.9.6.jar:2.9.6]
at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider._serialize(DefaultSerializerProvider.java:482) ~[jackson-databind-2.9.6.jar:2.9.6]
at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:319) ~[jackson-databind-2.9.6.jar:2.9.6]
at com.fasterxml.jackson.databind.ObjectMapper._configAndWriteValue(ObjectMapper.java:3905) ~[jackson-databind-2.9.6.jar:2.9.6]
at com.fasterxml.jackson.databind.ObjectMapper.writeValueAsString(ObjectMapper.java:3219) ~[jackson-databind-2.9.6.jar:2.9.6]
at petmenu.restControllers.ProdottoController.thirdStageInput(ProdottoController.java:92) ~[main/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_202]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_202]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_202]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_202]
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:209) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:102) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:891) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:797) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:991) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:925) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:974) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:877) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:661) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:851) ~[spring-webmvc-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) ~[tomcat-embed-websocket-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:109) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.0.9.RELEASE.jar:5.0.9.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) ~[tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) [tomcat-embed-core-8.5.34.jar:8.5.34]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-8.5.34.jar:8.5.34]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_202]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_202]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-8.5.34.jar:8.5.34]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_202]
Caused by: java.lang.NullPointerException: null
at petmenu.CustomProdottoSerializer.serialize(CustomProdottoSerializer.java:32) ~[main/:na]
at petmenu.CustomProdottoSerializer.serialize(CustomProdottoSerializer.java:1) ~[main/:na]
at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider._serialize(DefaultSerializerProvider.java:480) ~[jackson-databind-2.9.6.jar:2.9.6]
... 58 common frames omitted
А это интересный код
@Override
public void serialize(
Prodotto prod, JsonGenerator jgen, SerializerProvider serializer) throws IOException {
jgen.writeStartObject();
// getPeso_netto returns an Integer, that in the example is null
jgen.writeNumberField("peso_netto", prod.getPeso_netto());
Ответы 1
я бы предложил просто сделать нулевую проверку или, как вы предложили, обрабатывать через исключение.
@Override
public void serialize(
Prodotto prod, JsonGenerator jgen, SerializerProvider serializer) throws IOException {
jgen.writeStartObject();
// getPeso_netto returns an Integer, that in the example is null
if (prod.getPeso_netto() != null)
jgen.writeNumberField("peso_netto", prod.getPeso_netto());
else {
jgen.writeNullField("peso_netto");
}
РЕДАКТИРОВАТЬ Объяснение
метод JsonGenerator.writeNumberField имеет следующее тело метода:
public final void writeNumberField(String fieldName, int value) throws IOException {
this.writeFieldName(fieldName);
this.writeNumber(value);
}
как видите, метод ожидает int, а не Integer. Компилятор пытается автоматически преобразовать Integer в int. Это не удается с NPE, потому что Integer является нулевым объектом. Таким образом, NPE выбрасывается не «кодом библиотеки Джексона», а из JVM в точке, пытающейся передать автоматически упакованное нулевое значение как int методу Джексона.
Вы можете проверить это поведение с помощью следующего фрагмента:
Integer x = null;
x = 1 + x; // will throw NPE
Итак, есть новое исключение? Можете ли вы обновить свой вопрос с помощью редактирования и нового кода/исключения?
Мне жаль. Я думаю, что я не ясно выразился в своем последнем комментарии: writeNumberField выдает IOException [fastxml.github.io/jackson-core/javadoc/2.8/com/fasterxml/… Тогда я действительно не могу понять, откуда берется NullPointerException.
Я не уверен, что понял вашу точку зрения. Давай попробуем. Вы можете использовать несколько исключений в перехвате с помощью catch (IOException | NullPointerException e) {}. Из-за того, что NPE являются исключениями RuntimeException, компилятор не заставляет вас использовать try/catch. Но он заставляет вас обрабатывать IOException. Но вы можете просто добавить NPE, как написано выше, так вы поймаете NPE.
Спасибо за ваше объяснение. Это было действительно полезно, но я хочу понять, почему jackson выдает NPE, даже если ни один из его методов не должен этого делать, и почему он просто не пишет «null», как я читал в Интернете другими пользователями.
Поскольку NPE являются RuntimeException. Это означает, что вам не нужно объявлять их в теле метода с помощью throws. Таким образом, это не упоминается ни в каких документах. Причина этого в том, что 99% ситуаций, когда объект имеет значение null, от программиста этого не ожидают. Если он знает, что объект может быть нулевым, он выполняет проверку на нуль или ловит себя с помощью try/catch.
Я добавил объяснение NPE в вашем случае в своем ответе.
Вы говорите, что NPE выбрасывается не Джексоном, а JVM, пытающейся выполнить автобокс? Это имело бы смысл. Затем, если бы я переписал свой класс Prodotto, чтобы использовать int вместо Integer (гипотетически, я не хочу этого делать), я бы получил ожидаемое поведение: jackson, который пишет «null». Правильный?
Да для первого. JVM бросает NPE. Но изменение Integer на int не поможет, потому что примитивный тип в java никогда не может быть нулевым. все они имеют значения по умолчанию. Поэтому джексон написал бы в поле "0", а не нуль. Единственный способ - проверить null для себя.
Идеально. Я уже знал, что примитивы не могут быть нулевыми и не могут объяснить поведение, о котором я читал. Ответ прост: они говорили о writeFieldString, который, очевидно, принимает строку, которая в Java является не примитивом, а объектом, поэтому не запускает никакого механизма автоупаковки. В этом случае jackson напечатает «null». Спасибо большое за вашу помощь. Я отмечу ваш исходный ответ как принятый.
Что ж, я бы попробовал/поймал метод writeNumberField, но проблема в том, что он генерирует не NPE, а исключение IOException. Вот почему я подозреваю, что делаю что-то не так.