2

I am designing a database table, which will log Java exception messages.

For this case (and also out of interest) I want to know the (max.) message sizes I will encounter.

At the moment I am only interested in standard java language exceptions.

  • Is there any technical limitation on the message size?
  • What are the message lengths of the most common exceptions?
  • What is the average message length of all standard java exceptions?
  • Did the messages change a lot between different Java Versions?

Example:

try {
  //Some code, which throws an Exception
} catch(Exception ex) {
  String msg = ex.toString();    //Use toString, because sometimes there is no message
  int size = msg.length();       //How large can this be?
}

Throwable toString() implementation:

  public String toString() {
    String var1 = this.getClass().getName();
    String var2 = this.getLocalizedMessage();
    return var2 != null ? var1 + ": " + var2 : var1;
  }

Thanks for the replies. Bonus question: Is there a list with all the java language exception messages (in English), so I do not have to check the source files manually?

1
  • 2
    I would assume some relatively short length like 4096 characters should suffice for almost all Exception messages. If you can, test it in a dev / test environment and if you need more, go back and increase the limit before pushing to prod. Commented Jul 15, 2019 at 10:33

2 Answers 2

2

The Exception.getMessage() returns a String which doesn't have a length limit. There is no such thing as "standard" message length, it will depend on whatever libraries you are using in your codebase e.g. validation exceptions from javax.validation could be very long while NullPointerException often has no message.

You should get few days of logs from your application and write a regex to measure the expected length of an exception. Having this value you can make an educated guess.

Either define a VARCHAR column with given length and truncate the exception message when it's too long or define a blob/clob column and store the whole String. The deciding factor could be your database performance e.g. Oracle allows VARCHAR to have only 4000 bytes.

Sign up to request clarification or add additional context in comments.

2 Comments

Thanks for your suggestion. Maybe somebody else already did some research on this. Also some information about how the Java core people choose the exception messages/length would be interesting.
Don't guess engineering tasks, it's a waste of time. Get the logs and measure what you can expect for your application.
1

As far as I know there is no limitation on message length, nut in most cases The message is short in order to be practical. You probably will be safe with max size 2000 chars, but make it in DB as varchar so it takes only the space equal to the size of actual message in each case. Also exception's method toString() wouldn't give you any meaningful info. If there is no message then just store it as null or empty string "".

2 Comments

Thanks. I disagree with the "toString()" comment. e.g. new BigDecimal("asdas"); will throw a NumberFormatException but the message is empty. So toString() will return "java.lang.NumberFormatException" which is more useful than an empty String.
HectorLector - you might have a point, but if you want more info then you might want to store the stacktrace and not just an error message. In fact I did the same project at my current job and we stored the stacktrace. I wrote an Open source library called MgntUtils that actually has a util that extracts full or very smartly filtered stack trace as a String. If you are interested See this article: linkedin.com/pulse/… and there see the paragraph "Stacktrace noise filter"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.