Skip to content

Consider catching Exception instead of Throwable #3826

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Mar 13, 2023
Merged

Consider catching Exception instead of Throwable #3826

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
05b96fc
replace catching `Throwable` with `Exception`
JooHyukKim Mar 13, 2023
8197458
Update Java7Support.java
JooHyukKim Mar 13, 2023
64efcb3
Update Java7Support.java
JooHyukKim Mar 13, 2023
347f24b
Update NioPathDeserializer.java
JooHyukKim Mar 13, 2023
ae4f3a7
Update OptionalHandlerFactory.java
JooHyukKim Mar 13, 2023
d741ceb
Apply review
JooHyukKim Mar 13, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions src/main/java/com/fasterxml/jackson/databind/deser/std/StdValueInstantiator.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -341,7 +341,7 @@ public Object createFromString(DeserializationContext ctxt, String value) throws
if (_fromStringCreator != null) {
try {
return _fromStringCreator.call1(value);
} catch (Throwable t) {
} catch (Exception t) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, these (in this class) make sense.

return ctxt.handleInstantiationProblem(_fromStringCreator.getDeclaringClass(),
value, rewrapCtorProblem(ctxt, t));
}
Expand All @@ -357,7 +357,7 @@ public Object createFromInt(DeserializationContext ctxt, int value) throws IOExc
Object arg = Integer.valueOf(value);
try {
return _fromIntCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromIntCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0));
}
Expand All @@ -367,7 +367,7 @@ public Object createFromInt(DeserializationContext ctxt, int value) throws IOExc
Object arg = Long.valueOf(value);
try {
return _fromLongCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromLongCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0));
}
Expand All @@ -377,7 +377,7 @@ public Object createFromInt(DeserializationContext ctxt, int value) throws IOExc
Object arg = BigInteger.valueOf(value);
try {
return _fromBigIntegerCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromBigIntegerCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0)
);
Expand All @@ -394,7 +394,7 @@ public Object createFromLong(DeserializationContext ctxt, long value) throws IOE
Long arg = Long.valueOf(value);
try {
return _fromLongCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromLongCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0)
);
Expand All @@ -405,7 +405,7 @@ arg, rewrapCtorProblem(ctxt, t0)
BigInteger arg = BigInteger.valueOf(value);
try {
return _fromBigIntegerCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromBigIntegerCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0)
);
Expand All @@ -421,7 +421,7 @@ public Object createFromBigInteger(DeserializationContext ctxt, BigInteger value
if (_fromBigIntegerCreator != null) {
try {
return _fromBigIntegerCreator.call1(value);
} catch (Throwable t) {
} catch (Exception t) {
return ctxt.handleInstantiationProblem(_fromBigIntegerCreator.getDeclaringClass(),
value, rewrapCtorProblem(ctxt, t)
);
Expand All @@ -438,7 +438,7 @@ public Object createFromDouble(DeserializationContext ctxt, double value) throws
Double arg = Double.valueOf(value);
try {
return _fromDoubleCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromDoubleCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0));
}
Expand All @@ -448,7 +448,7 @@ public Object createFromDouble(DeserializationContext ctxt, double value) throws
BigDecimal arg = BigDecimal.valueOf(value);
try {
return _fromBigDecimalCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromBigDecimalCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0));
}
Expand All @@ -463,7 +463,7 @@ public Object createFromBigDecimal(DeserializationContext ctxt, BigDecimal value
if (_fromBigDecimalCreator != null) {
try {
return _fromBigDecimalCreator.call1(value);
} catch (Throwable t) {
} catch (Exception t) {
return ctxt.handleInstantiationProblem(_fromBigDecimalCreator.getDeclaringClass(),
value, rewrapCtorProblem(ctxt, t)
);
Expand All @@ -479,7 +479,7 @@ value, rewrapCtorProblem(ctxt, t)
if (dbl != null) {
try {
return _fromDoubleCreator.call1(dbl);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromDoubleCreator.getDeclaringClass(),
dbl, rewrapCtorProblem(ctxt, t0));
}
Expand Down Expand Up @@ -507,7 +507,7 @@ public Object createFromBoolean(DeserializationContext ctxt, boolean value) thro
final Boolean arg = Boolean.valueOf(value);
try {
return _fromBooleanCreator.call1(arg);
} catch (Throwable t0) {
} catch (Exception t0) {
return ctxt.handleInstantiationProblem(_fromBooleanCreator.getDeclaringClass(),
arg, rewrapCtorProblem(ctxt, t0));
}
Expand Down Expand Up @@ -654,7 +654,7 @@ private Object _createUsingDelegate(AnnotatedWithParams delegateCreator,
}
// and then try calling with full set of arguments
return delegateCreator.call(args);
} catch (Throwable t) {
} catch (Exception t) {
throw rewrapCtorProblem(ctxt, t);
}
}
Expand Down
6 changes: 3 additions & 3 deletions src/main/java/com/fasterxml/jackson/databind/ext/DOMDeserializer.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,18 +35,18 @@ public abstract class DOMDeserializer<T> extends FromStringDeserializer<T>
parserFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
} catch(ParserConfigurationException pce) {
// not much point to do anything; could log but...
} catch (Error e) {
} catch (Exception e) {
// 14-Jul-2016, tatu: Not sure how or why, but during code coverage runs
// (via Cobertura) we get `java.lang.AbstractMethodError` so... ignore that too
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// 14-Jul-2016, tatu: Not sure how or why, but during code coverage runs
// (via Cobertura) we get java.lang.AbstractMethodError so... ignore that too

There was no trace of code coverage tool named Cobertura in databind.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why catch Exception though? Remove the Error catching but don't add the Exception handling.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, let's just remove altogether in this case.But careful with following ones.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean, keep catching ParserConfigurationException in line 36 right? Just to be sure

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep all checks except for the Error check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.


// [databind#2589] add two more settings just in case
try {
parserFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
} catch (Throwable t) { } // as per previous one, nothing much to do
} catch (Exception t) { } // as per previous one, nothing much to do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case need to leave Exception like here, for unsupported feature.

(or could consider catching ParserConfigurationException -- but for now I prefer Exception).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case need to leave Exception like here, for unsupported feature.

I do prefer ParserConfigurationException for exact same reason because setFeature method itself is documented to throw ParserConfigurationException for unsupported feature. Then question becomes "can we trust javax.xml.parsers and its documentation?" 😅

image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. I do not (alas!) trust them NOT to throw, say, IllegalArgumentException (or NPE as actually documented).
And I say this as maintainer of Woodstox which tries to follow API spec but which still occasional has differed (esp. where spec was incomplete).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exception it is then~

try {
parserFactory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
} catch (Throwable t) { } // as per previous one, nothing much to do
} catch (Exception t) { } // as per previous one, nothing much to do
DEFAULT_PARSER_FACTORY = parserFactory;
}

Expand Down
2 changes: 1 addition & 1 deletion src/main/java/com/fasterxml/jackson/databind/ext/Java7Support.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ public abstract class Java7Support
try {
Class<?> cls = Class.forName("com.fasterxml.jackson.databind.ext.Java7SupportImpl");
impl = (Java7Support) ClassUtil.createInstance(cls, false);
} catch (Throwable t) {
} catch (Exception | LinkageError t) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we are trying to catch Exceptions or Errors from either Class.forName or ClassUtil.createInstance.

  • Class.forName throws LinkageError/ExceptionInInitializerError/ClassNotFoundException are all covered with current changes.
  • I suppose ClassUtil.createInstance should only throw Exception or its subclass

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave this as-is, unless we can somehow test behavior. My concern is wrt platforms where loading fails, and removing general catch would expose things other than LinkageErrors.

// 09-Sep-2019, tatu: Used to log earlier, but with 2.10.0 let's not log
// java.util.logging.Logger.getLogger(Java7Support.class.getName())
// .warning("Unable to load JDK7 annotations (@ConstructorProperties, @Transient): no Java7 annotation support added");
Expand Down
5 changes: 3 additions & 2 deletions src/main/java/com/fasterxml/jackson/databind/ext/NioPathDeserializer.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
import java.nio.file.Path;
import java.nio.file.Paths;
import java.nio.file.spi.FileSystemProvider;
import java.util.ServiceConfigurationError;
import java.util.ServiceLoader;

import com.fasterxml.jackson.core.JsonParser;
Expand Down Expand Up @@ -77,11 +78,11 @@ public Path deserialize(JsonParser p, DeserializationContext ctxt) throws IOExce
}
}
return (Path) ctxt.handleInstantiationProblem(handledType(), value, cause);
} catch (Throwable e) {
} catch (Exception | ServiceConfigurationError e) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we are after ServiceConfigurationError thrown by ServiceLoader.load(FileSystemProvider.class) or any Exception(for keeping consistency's sake?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's only catch ServiceConfigurationError. Otherwise I think we'll actually catch whatever handleInstantiationProblem() usually throws....

e.addSuppressed(cause);
return (Path) ctxt.handleInstantiationProblem(handledType(), value, e);
}
} catch (Throwable e) {
} catch (Exception e) {
return (Path) ctxt.handleInstantiationProblem(handledType(), value, e);
}
}
Expand Down
8 changes: 4 additions & 4 deletions src/main/java/com/fasterxml/jackson/databind/ext/OptionalHandlerFactory.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ public class OptionalHandlerFactory implements java.io.Serializable
try {
node = org.w3c.dom.Node.class;
doc = org.w3c.dom.Document.class;
} catch (Throwable e) {
} catch (NoClassDefFoundError | Exception e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave exception catching in this particular class as it was; we don't have tests to verify that loading would not fail via Errors. Even if sort of unlikely, I think LinkageError etc might occur.

// not optimal but will do
// 02-Nov-2020, Xakep_SDK: Remove java.logging module dependency
// Logger.getLogger(OptionalHandlerFactory.class.getName())
Expand All @@ -73,7 +73,7 @@ public class OptionalHandlerFactory implements java.io.Serializable
Java7Handlers x = null;
try {
x = Java7Handlers.instance();
} catch (Throwable t) { }
} catch (Exception t) { }
_jdk7Helper = x;
}

Expand Down Expand Up @@ -231,7 +231,7 @@ private Object instantiate(String className, JavaType valueType)
{
try {
return instantiate(Class.forName(className), valueType);
} catch (Throwable e) {
} catch (Exception e) {
throw new IllegalStateException("Failed to find class `"
+className+"` for handling values of type "+ClassUtil.getTypeDescription(valueType)
+", problem: ("+e.getClass().getName()+") "+e.getMessage());
Expand All @@ -242,7 +242,7 @@ private Object instantiate(Class<?> handlerClass, JavaType valueType)
{
try {
return ClassUtil.createInstance(handlerClass, false);
} catch (Throwable e) {
} catch (Exception e) {
throw new IllegalStateException("Failed to create instance of `"
+handlerClass.getName()+"` for handling values of type "+ClassUtil.getTypeDescription(valueType)
+", problem: ("+e.getClass().getName()+") "+e.getMessage());
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/com/fasterxml/jackson/databind/introspect/JacksonAnnotationIntrospector.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ public class JacksonAnnotationIntrospector
Java7Support x = null;
try {
x = Java7Support.instance();
} catch (Throwable t) { }
} catch (Exception t) { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, leave catching Throwable as-is.

_java7Helper = x;
}

Expand Down
6 changes: 3 additions & 3 deletions src/main/java/com/fasterxml/jackson/databind/util/ClassUtil.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1179,7 +1179,7 @@ public static boolean isJDKClass(Class<?> rawType) {
public static boolean isJDK17OrAbove() {
try {
return getJDKMajorVersion() >= 17;
} catch (Throwable t) {
} catch (Exception t) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No real tests to see that this wont start failing; let's leave catching Throwable

Copy link
Member

@pjfanning pjfanning Mar 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in cases where we don't want to make too big a change, could we consider something like the ExceptionUtil I documented in https://medium.com/system-weakness/cwe-248-uncaught-exception-in-java-b6f4ee8daf14 ? Errors like OutOfMemoryError/VirtualMachineError and ThreadDeathError should be rethrown. LinkageError is something that we would need to consider on a case by case basis.

Copy link
Member Author

@JooHyukKim JooHyukKim Mar 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we consider something like the ExceptionUtil

Good idea for cases where we are catching Throwable. --Errors are do not change quite often, so we may be able to list down most of Errors and make decisions whether to catch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmh. Perhaps for cases where we can determine limits and so on, but allow-listing requires quite a bit of work to get to suitable set.

I think the idea is valid, but I feel not for this particular use case; given that we already catch safely cases during initialization: if we were starting from scratch, I would agree in doing things incrementally. But in this particular case let's keep things simple even if not optimal: I don't want accidental breakages on legacy platforms when there isn't specific problem to fix (as far as I can see).
This is assuming this is more like pro-active maintenance, general idea of trying to avoid catching Throwable (which I agree with, at general level )

Copy link
Member Author

@JooHyukKim JooHyukKim Mar 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's keep things simple even if not optimal: I don't want accidental breakages on legacy platforms when there isn't specific problem to fix (as far as I can see).

True. And maybe at some point explicit handling of ‘Error’s will be more sound and safe 🧐

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If leaving catch (Throwable t) cases (same as before) seems off. How about simply "contain" with a single no-op util method? So we can keep track of and write notes about plans? Would look something like

/**
 * Util method to keep track of cases where generic `Throwable` is caught. 
 *  https://github.com  to keep record of... 
 */
public static void keepTrackOfThrowable(Throwable t) {
    throw t;
}

Then would be used in our case

try {
      return getJDKMajorVersion() >= 17;
} catch (Throwable t) {
      keepTrackOfThrowable(t); // <----- here is no-op
      System.err.println("Failed to determine JDK major version: "+t);
      return false;
}

This solution might seem odd, but will provide better starting point. -- I checked the classes where I reverted back to catching Throwable, suggested solution above seems doable becasue and all of them simple catch Throwable and do nothing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, the PR is merged. I mention this conversation on the PR itself so we can always come back and not fresh-start.

System.err.println("Failed to determine JDK major version, assuming pre-JDK-17; problem: "+t);
return false;
}
Expand Down Expand Up @@ -1300,10 +1300,10 @@ public static Method[] getClassMethods(Class<?> cls)
}
try {
return contextClass.getDeclaredMethods(); // Cross fingers
} catch (Throwable t) {
} catch (Exception t) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, I think, can change to only catch Exception

return _failGetClassMethods(cls, t);
}
} catch (Throwable t) {
} catch (Exception t) {
return _failGetClassMethods(cls, t);
}
}
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/com/fasterxml/jackson/databind/util/StdDateFormat.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ public class StdDateFormat
+"(\\.\\d+)?" // optional second fractions
+"(Z|[+-]\\d\\d(?:[:]?\\d\\d)?)?" // optional timeoffset/Z
);
} catch (Throwable t) {
} catch (Exception t) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, makes sense.

throw new RuntimeException(t);
}
PATTERN_ISO8601 = p;
Expand Down