Difference between e.getMessage() and e.getLocalizedMessage()
- I am using these both methods to get the message thrown by the catch
block while performing error handling - Both of them get me the message from the error handling but what
exactly does these two differ with - I did some searching from internet and came up with this answer from
here
Java Exceptions inherit their getMessage and getLocalizedMessage
methods from Throwable (see the related link). The difference is that
subclasses should override getLocalizedMessage to provide a
locale-specific message. For example, imaging that you're adapting
code from an American-English speaking company/group to a
British-English group. You may want to create custom Exception classes
which override the getLocalizedMessage to correct spelling and grammer
to what the users and developers who will be using your code might
expect. This can also be used for actual translations of Exception
messages.
Questions::
Does that mean
language specific
implementations ? like if i usee.getLocalizedMessage()
for
example my app inEnglish
- error will be thrown inEnglish
, if i
use my app inSpanish
- then error will be thrown inSpanish
Need some clear explanation on where and when i can use these methods
to my use
java

add a comment |
- I am using these both methods to get the message thrown by the catch
block while performing error handling - Both of them get me the message from the error handling but what
exactly does these two differ with - I did some searching from internet and came up with this answer from
here
Java Exceptions inherit their getMessage and getLocalizedMessage
methods from Throwable (see the related link). The difference is that
subclasses should override getLocalizedMessage to provide a
locale-specific message. For example, imaging that you're adapting
code from an American-English speaking company/group to a
British-English group. You may want to create custom Exception classes
which override the getLocalizedMessage to correct spelling and grammer
to what the users and developers who will be using your code might
expect. This can also be used for actual translations of Exception
messages.
Questions::
Does that mean
language specific
implementations ? like if i usee.getLocalizedMessage()
for
example my app inEnglish
- error will be thrown inEnglish
, if i
use my app inSpanish
- then error will be thrown inSpanish
Need some clear explanation on where and when i can use these methods
to my use
java

1
Yes, it means locale (language, culture) specific implementations. What's wrong with official documentation?
– default locale
Jul 28 '14 at 4:38
add a comment |
- I am using these both methods to get the message thrown by the catch
block while performing error handling - Both of them get me the message from the error handling but what
exactly does these two differ with - I did some searching from internet and came up with this answer from
here
Java Exceptions inherit their getMessage and getLocalizedMessage
methods from Throwable (see the related link). The difference is that
subclasses should override getLocalizedMessage to provide a
locale-specific message. For example, imaging that you're adapting
code from an American-English speaking company/group to a
British-English group. You may want to create custom Exception classes
which override the getLocalizedMessage to correct spelling and grammer
to what the users and developers who will be using your code might
expect. This can also be used for actual translations of Exception
messages.
Questions::
Does that mean
language specific
implementations ? like if i usee.getLocalizedMessage()
for
example my app inEnglish
- error will be thrown inEnglish
, if i
use my app inSpanish
- then error will be thrown inSpanish
Need some clear explanation on where and when i can use these methods
to my use
java

- I am using these both methods to get the message thrown by the catch
block while performing error handling - Both of them get me the message from the error handling but what
exactly does these two differ with - I did some searching from internet and came up with this answer from
here
Java Exceptions inherit their getMessage and getLocalizedMessage
methods from Throwable (see the related link). The difference is that
subclasses should override getLocalizedMessage to provide a
locale-specific message. For example, imaging that you're adapting
code from an American-English speaking company/group to a
British-English group. You may want to create custom Exception classes
which override the getLocalizedMessage to correct spelling and grammer
to what the users and developers who will be using your code might
expect. This can also be used for actual translations of Exception
messages.
Questions::
Does that mean
language specific
implementations ? like if i usee.getLocalizedMessage()
for
example my app inEnglish
- error will be thrown inEnglish
, if i
use my app inSpanish
- then error will be thrown inSpanish
Need some clear explanation on where and when i can use these methods
to my use
java

java

edited Jul 28 '14 at 4:55
Xaver Kapeller
39.1k107776
39.1k107776
asked Jul 28 '14 at 4:35


DevrathDevrath
22.7k40132186
22.7k40132186
1
Yes, it means locale (language, culture) specific implementations. What's wrong with official documentation?
– default locale
Jul 28 '14 at 4:38
add a comment |
1
Yes, it means locale (language, culture) specific implementations. What's wrong with official documentation?
– default locale
Jul 28 '14 at 4:38
1
1
Yes, it means locale (language, culture) specific implementations. What's wrong with official documentation?
– default locale
Jul 28 '14 at 4:38
Yes, it means locale (language, culture) specific implementations. What's wrong with official documentation?
– default locale
Jul 28 '14 at 4:38
add a comment |
7 Answers
7
active
oldest
votes
As everybody has mentioned above --
To my understanding, getMessage()
returns the name of the exception. getLocalizedMessage()
returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage()
on must have overridden the getLocalizedMessage()
method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
In addition to that, I would like to put some code segment explaining how to use it.
How to use it
Java does nothing magical, but it does provide a way to make our life easier.
To use getLocalizedMessage()
effectively, we have to override the default behavior.
import java.util.ResourceBundle;
public class MyLocalizedThrowable extends Throwable {
ResourceBundle labels = ResourceBundle.getBundle("loc.exc.test.message");
private static final long serialVersionUID = 1L;
public MyLocalizedThrowable(String messageKey) {
super(messageKey);
}
public String getLocalizedMessage() {
return labels.getString(getMessage());
}
}
java.util.ResourceBundle
is used to do localization.
In this example, you have to place language-specific property files in the loc/exc/test
path. For example:
message_fr.properties (containing some key and value):
key1=this is key one in France
message.properties (containing some key and value):
key1=this is key one in English
Now, let us assume that our exception generator class is something like
public class ExceptionGenerator {
public void generateException() throws MyLocalizedThrowable {
throw new MyLocalizedThrowable("key1");
}
}
and the main class is:
public static void main(String args) {
//Locale.setDefault(Locale.FRANCE);
ExceptionGenerator eg = new ExceptionGenerator();
try {
eg.generateException();
} catch (MyLocalizedThrowable e) {
System.out.println(e.getLocalizedMessage());
}
}
By default, it will return the "English" key value if you are executing in the "English" environment. If you set the local to France, you will get the output from the message_fr file.
When to use it
If your application needs to support l10n/i18n you need to use it. But most of the application does not need to, as most error messages are not for the end customer, but for the support engineer/development engineer.
3
"To my understanding, getMessage() returns the name of the exception." This is just wrong. The name of the Exception is found frome.getClass().getSimpleName()
.new NullPointerException().getMessage()
returns "null", not "NullPointerException".
– Philip Whitehouse
Feb 4 '17 at 0:21
The trap here, though, is that the method doesn't actually take the locale, so it isn't always possible to get the locale of the user. In particular, the way the exception in this answer has been implemented will only properly localise the exception for a GUI application. For a server-side application, the default locale of the JVM is not the same as that of the user, so the best policy is never to call ResourceBundle.getBundle(String) and always to provide the user's actual locale. (For instance, with web applications, you typically receive information about the user's locale in a header.)
– Trejkaz
Jul 9 '18 at 2:15
add a comment |
It is really surprising - Check the openJDK 7 code of Throwable.java class.
Implementation of getLocalizedMessage
is -
390 public String getLocalizedMessage() {
391 return getMessage();
392 }
And implemenation of getMessage
is -
376 public String getMessage() {
377 return detailMessage;
378 }
And
130 private String detailMessage;
There is no change in implemenation of both method but documentation.
11
The documentation clearly says "Subclasses may override this method in order to produce a locale-specific message. For subclasses that do not override this method, the default implementation returns the same result as getMessage()."
– fool4jesus
Aug 31 '15 at 18:14
add a comment |
no. it definitely does not mean language specific implementations. it means implementations that use an internationalization (aka i18n) mechanism. see this page for more details of what resource bundles are and how to use them.
the gist is that you place any text in resource files, of which you have many (one per locale/language/etc) and your code uses a mechanism to look up the text in the correct resource file (the link i provided goes into details).
as to when and where this gets used, its entirely up to you. normally you'd only be concerned about this when you want to present an exception to a non-technical user, who may not know english that well. so for example, if you're just writing to log (which commonly only technical users read and so isnt a common i18n target) you'd do:
try {
somethingDangerous();
} catch (Exception e) {
log.error("got this: "+e.getMessage());
}
but if you intend to display the exception message to the screen (as a small dialogue, for example) then you might want to display the message in a local language:
try {
somethingDangerous();
} catch (Exception e) {
JOptionPane.showMessageDialog(frame,
e.getLocalizedMessage(),
"Error", <---- also best be taken from i18n
JOptionPane.ERROR_MESSAGE);
}
add a comment |
public String getMessage()
Returns the detail message string of this throwable.
public String getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage()
.
In your case e is nothing but the object of exception ...
getLocalizedMessage()
u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
add a comment |
This is what the Throwable.java class have to say. Maybe it can help someone:
/**
* Returns the detail message string of this throwable.
*
* @return the detail message string of this {@code Throwable} instance
* (which may be {@code null}).
*/
public String getMessage() {
return detailMessage;
}
/**
* Creates a localized description of this throwable.
* Subclasses may override this method in order to produce a
* locale-specific message. For subclasses that do not override this
* method, the default implementation returns the same result as
* {@code getMessage()}.
*
* @return The localized description of this throwable.
* @since JDK1.1
*/
public String getLocalizedMessage() {
return getMessage();
}
add a comment |
To my understanding, getMessage returns the name of the exception. getLocalizedMessage returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage on must have overridden the getLocalizedMessage method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
So in most cases, the result will be the same but in some cases it will return the exception name in the language of the region where the program is being run.
Does that mean language specific implementations ? like if i use
e.getLocalizedMessage() for example my app in English - error will be
thrown in English , if i use my app in Spanish - then error will be
thrown in Spanish
public String
getMessage()
Returns the detail message string of this throwable.
public String
getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage().
In your case e is nothing but the object of exception ...
getLocalizedMessage() u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
Read more...
add a comment |
To my understanding, getMessage
returns the name of the exception.
getLocalizedMessage
returns the name of the exception in the local language of the user (Chinese, Japanese etc.).
In order to make this work, the class you are calling getLocalizedMessage
on must have overridden the getLocalizedMessage
method.
If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage
.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f24988491%2fdifference-between-e-getmessage-and-e-getlocalizedmessage%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
As everybody has mentioned above --
To my understanding, getMessage()
returns the name of the exception. getLocalizedMessage()
returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage()
on must have overridden the getLocalizedMessage()
method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
In addition to that, I would like to put some code segment explaining how to use it.
How to use it
Java does nothing magical, but it does provide a way to make our life easier.
To use getLocalizedMessage()
effectively, we have to override the default behavior.
import java.util.ResourceBundle;
public class MyLocalizedThrowable extends Throwable {
ResourceBundle labels = ResourceBundle.getBundle("loc.exc.test.message");
private static final long serialVersionUID = 1L;
public MyLocalizedThrowable(String messageKey) {
super(messageKey);
}
public String getLocalizedMessage() {
return labels.getString(getMessage());
}
}
java.util.ResourceBundle
is used to do localization.
In this example, you have to place language-specific property files in the loc/exc/test
path. For example:
message_fr.properties (containing some key and value):
key1=this is key one in France
message.properties (containing some key and value):
key1=this is key one in English
Now, let us assume that our exception generator class is something like
public class ExceptionGenerator {
public void generateException() throws MyLocalizedThrowable {
throw new MyLocalizedThrowable("key1");
}
}
and the main class is:
public static void main(String args) {
//Locale.setDefault(Locale.FRANCE);
ExceptionGenerator eg = new ExceptionGenerator();
try {
eg.generateException();
} catch (MyLocalizedThrowable e) {
System.out.println(e.getLocalizedMessage());
}
}
By default, it will return the "English" key value if you are executing in the "English" environment. If you set the local to France, you will get the output from the message_fr file.
When to use it
If your application needs to support l10n/i18n you need to use it. But most of the application does not need to, as most error messages are not for the end customer, but for the support engineer/development engineer.
3
"To my understanding, getMessage() returns the name of the exception." This is just wrong. The name of the Exception is found frome.getClass().getSimpleName()
.new NullPointerException().getMessage()
returns "null", not "NullPointerException".
– Philip Whitehouse
Feb 4 '17 at 0:21
The trap here, though, is that the method doesn't actually take the locale, so it isn't always possible to get the locale of the user. In particular, the way the exception in this answer has been implemented will only properly localise the exception for a GUI application. For a server-side application, the default locale of the JVM is not the same as that of the user, so the best policy is never to call ResourceBundle.getBundle(String) and always to provide the user's actual locale. (For instance, with web applications, you typically receive information about the user's locale in a header.)
– Trejkaz
Jul 9 '18 at 2:15
add a comment |
As everybody has mentioned above --
To my understanding, getMessage()
returns the name of the exception. getLocalizedMessage()
returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage()
on must have overridden the getLocalizedMessage()
method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
In addition to that, I would like to put some code segment explaining how to use it.
How to use it
Java does nothing magical, but it does provide a way to make our life easier.
To use getLocalizedMessage()
effectively, we have to override the default behavior.
import java.util.ResourceBundle;
public class MyLocalizedThrowable extends Throwable {
ResourceBundle labels = ResourceBundle.getBundle("loc.exc.test.message");
private static final long serialVersionUID = 1L;
public MyLocalizedThrowable(String messageKey) {
super(messageKey);
}
public String getLocalizedMessage() {
return labels.getString(getMessage());
}
}
java.util.ResourceBundle
is used to do localization.
In this example, you have to place language-specific property files in the loc/exc/test
path. For example:
message_fr.properties (containing some key and value):
key1=this is key one in France
message.properties (containing some key and value):
key1=this is key one in English
Now, let us assume that our exception generator class is something like
public class ExceptionGenerator {
public void generateException() throws MyLocalizedThrowable {
throw new MyLocalizedThrowable("key1");
}
}
and the main class is:
public static void main(String args) {
//Locale.setDefault(Locale.FRANCE);
ExceptionGenerator eg = new ExceptionGenerator();
try {
eg.generateException();
} catch (MyLocalizedThrowable e) {
System.out.println(e.getLocalizedMessage());
}
}
By default, it will return the "English" key value if you are executing in the "English" environment. If you set the local to France, you will get the output from the message_fr file.
When to use it
If your application needs to support l10n/i18n you need to use it. But most of the application does not need to, as most error messages are not for the end customer, but for the support engineer/development engineer.
3
"To my understanding, getMessage() returns the name of the exception." This is just wrong. The name of the Exception is found frome.getClass().getSimpleName()
.new NullPointerException().getMessage()
returns "null", not "NullPointerException".
– Philip Whitehouse
Feb 4 '17 at 0:21
The trap here, though, is that the method doesn't actually take the locale, so it isn't always possible to get the locale of the user. In particular, the way the exception in this answer has been implemented will only properly localise the exception for a GUI application. For a server-side application, the default locale of the JVM is not the same as that of the user, so the best policy is never to call ResourceBundle.getBundle(String) and always to provide the user's actual locale. (For instance, with web applications, you typically receive information about the user's locale in a header.)
– Trejkaz
Jul 9 '18 at 2:15
add a comment |
As everybody has mentioned above --
To my understanding, getMessage()
returns the name of the exception. getLocalizedMessage()
returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage()
on must have overridden the getLocalizedMessage()
method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
In addition to that, I would like to put some code segment explaining how to use it.
How to use it
Java does nothing magical, but it does provide a way to make our life easier.
To use getLocalizedMessage()
effectively, we have to override the default behavior.
import java.util.ResourceBundle;
public class MyLocalizedThrowable extends Throwable {
ResourceBundle labels = ResourceBundle.getBundle("loc.exc.test.message");
private static final long serialVersionUID = 1L;
public MyLocalizedThrowable(String messageKey) {
super(messageKey);
}
public String getLocalizedMessage() {
return labels.getString(getMessage());
}
}
java.util.ResourceBundle
is used to do localization.
In this example, you have to place language-specific property files in the loc/exc/test
path. For example:
message_fr.properties (containing some key and value):
key1=this is key one in France
message.properties (containing some key and value):
key1=this is key one in English
Now, let us assume that our exception generator class is something like
public class ExceptionGenerator {
public void generateException() throws MyLocalizedThrowable {
throw new MyLocalizedThrowable("key1");
}
}
and the main class is:
public static void main(String args) {
//Locale.setDefault(Locale.FRANCE);
ExceptionGenerator eg = new ExceptionGenerator();
try {
eg.generateException();
} catch (MyLocalizedThrowable e) {
System.out.println(e.getLocalizedMessage());
}
}
By default, it will return the "English" key value if you are executing in the "English" environment. If you set the local to France, you will get the output from the message_fr file.
When to use it
If your application needs to support l10n/i18n you need to use it. But most of the application does not need to, as most error messages are not for the end customer, but for the support engineer/development engineer.
As everybody has mentioned above --
To my understanding, getMessage()
returns the name of the exception. getLocalizedMessage()
returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage()
on must have overridden the getLocalizedMessage()
method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
In addition to that, I would like to put some code segment explaining how to use it.
How to use it
Java does nothing magical, but it does provide a way to make our life easier.
To use getLocalizedMessage()
effectively, we have to override the default behavior.
import java.util.ResourceBundle;
public class MyLocalizedThrowable extends Throwable {
ResourceBundle labels = ResourceBundle.getBundle("loc.exc.test.message");
private static final long serialVersionUID = 1L;
public MyLocalizedThrowable(String messageKey) {
super(messageKey);
}
public String getLocalizedMessage() {
return labels.getString(getMessage());
}
}
java.util.ResourceBundle
is used to do localization.
In this example, you have to place language-specific property files in the loc/exc/test
path. For example:
message_fr.properties (containing some key and value):
key1=this is key one in France
message.properties (containing some key and value):
key1=this is key one in English
Now, let us assume that our exception generator class is something like
public class ExceptionGenerator {
public void generateException() throws MyLocalizedThrowable {
throw new MyLocalizedThrowable("key1");
}
}
and the main class is:
public static void main(String args) {
//Locale.setDefault(Locale.FRANCE);
ExceptionGenerator eg = new ExceptionGenerator();
try {
eg.generateException();
} catch (MyLocalizedThrowable e) {
System.out.println(e.getLocalizedMessage());
}
}
By default, it will return the "English" key value if you are executing in the "English" environment. If you set the local to France, you will get the output from the message_fr file.
When to use it
If your application needs to support l10n/i18n you need to use it. But most of the application does not need to, as most error messages are not for the end customer, but for the support engineer/development engineer.
edited Dec 8 '16 at 20:55


Dan Getz
6,52962450
6,52962450
answered Jul 28 '14 at 6:14
dgmdgm
1,39011422
1,39011422
3
"To my understanding, getMessage() returns the name of the exception." This is just wrong. The name of the Exception is found frome.getClass().getSimpleName()
.new NullPointerException().getMessage()
returns "null", not "NullPointerException".
– Philip Whitehouse
Feb 4 '17 at 0:21
The trap here, though, is that the method doesn't actually take the locale, so it isn't always possible to get the locale of the user. In particular, the way the exception in this answer has been implemented will only properly localise the exception for a GUI application. For a server-side application, the default locale of the JVM is not the same as that of the user, so the best policy is never to call ResourceBundle.getBundle(String) and always to provide the user's actual locale. (For instance, with web applications, you typically receive information about the user's locale in a header.)
– Trejkaz
Jul 9 '18 at 2:15
add a comment |
3
"To my understanding, getMessage() returns the name of the exception." This is just wrong. The name of the Exception is found frome.getClass().getSimpleName()
.new NullPointerException().getMessage()
returns "null", not "NullPointerException".
– Philip Whitehouse
Feb 4 '17 at 0:21
The trap here, though, is that the method doesn't actually take the locale, so it isn't always possible to get the locale of the user. In particular, the way the exception in this answer has been implemented will only properly localise the exception for a GUI application. For a server-side application, the default locale of the JVM is not the same as that of the user, so the best policy is never to call ResourceBundle.getBundle(String) and always to provide the user's actual locale. (For instance, with web applications, you typically receive information about the user's locale in a header.)
– Trejkaz
Jul 9 '18 at 2:15
3
3
"To my understanding, getMessage() returns the name of the exception." This is just wrong. The name of the Exception is found from
e.getClass().getSimpleName()
. new NullPointerException().getMessage()
returns "null", not "NullPointerException".– Philip Whitehouse
Feb 4 '17 at 0:21
"To my understanding, getMessage() returns the name of the exception." This is just wrong. The name of the Exception is found from
e.getClass().getSimpleName()
. new NullPointerException().getMessage()
returns "null", not "NullPointerException".– Philip Whitehouse
Feb 4 '17 at 0:21
The trap here, though, is that the method doesn't actually take the locale, so it isn't always possible to get the locale of the user. In particular, the way the exception in this answer has been implemented will only properly localise the exception for a GUI application. For a server-side application, the default locale of the JVM is not the same as that of the user, so the best policy is never to call ResourceBundle.getBundle(String) and always to provide the user's actual locale. (For instance, with web applications, you typically receive information about the user's locale in a header.)
– Trejkaz
Jul 9 '18 at 2:15
The trap here, though, is that the method doesn't actually take the locale, so it isn't always possible to get the locale of the user. In particular, the way the exception in this answer has been implemented will only properly localise the exception for a GUI application. For a server-side application, the default locale of the JVM is not the same as that of the user, so the best policy is never to call ResourceBundle.getBundle(String) and always to provide the user's actual locale. (For instance, with web applications, you typically receive information about the user's locale in a header.)
– Trejkaz
Jul 9 '18 at 2:15
add a comment |
It is really surprising - Check the openJDK 7 code of Throwable.java class.
Implementation of getLocalizedMessage
is -
390 public String getLocalizedMessage() {
391 return getMessage();
392 }
And implemenation of getMessage
is -
376 public String getMessage() {
377 return detailMessage;
378 }
And
130 private String detailMessage;
There is no change in implemenation of both method but documentation.
11
The documentation clearly says "Subclasses may override this method in order to produce a locale-specific message. For subclasses that do not override this method, the default implementation returns the same result as getMessage()."
– fool4jesus
Aug 31 '15 at 18:14
add a comment |
It is really surprising - Check the openJDK 7 code of Throwable.java class.
Implementation of getLocalizedMessage
is -
390 public String getLocalizedMessage() {
391 return getMessage();
392 }
And implemenation of getMessage
is -
376 public String getMessage() {
377 return detailMessage;
378 }
And
130 private String detailMessage;
There is no change in implemenation of both method but documentation.
11
The documentation clearly says "Subclasses may override this method in order to produce a locale-specific message. For subclasses that do not override this method, the default implementation returns the same result as getMessage()."
– fool4jesus
Aug 31 '15 at 18:14
add a comment |
It is really surprising - Check the openJDK 7 code of Throwable.java class.
Implementation of getLocalizedMessage
is -
390 public String getLocalizedMessage() {
391 return getMessage();
392 }
And implemenation of getMessage
is -
376 public String getMessage() {
377 return detailMessage;
378 }
And
130 private String detailMessage;
There is no change in implemenation of both method but documentation.
It is really surprising - Check the openJDK 7 code of Throwable.java class.
Implementation of getLocalizedMessage
is -
390 public String getLocalizedMessage() {
391 return getMessage();
392 }
And implemenation of getMessage
is -
376 public String getMessage() {
377 return detailMessage;
378 }
And
130 private String detailMessage;
There is no change in implemenation of both method but documentation.
answered Jul 28 '14 at 4:56


Subhrajyoti MajumderSubhrajyoti Majumder
34k105991
34k105991
11
The documentation clearly says "Subclasses may override this method in order to produce a locale-specific message. For subclasses that do not override this method, the default implementation returns the same result as getMessage()."
– fool4jesus
Aug 31 '15 at 18:14
add a comment |
11
The documentation clearly says "Subclasses may override this method in order to produce a locale-specific message. For subclasses that do not override this method, the default implementation returns the same result as getMessage()."
– fool4jesus
Aug 31 '15 at 18:14
11
11
The documentation clearly says "Subclasses may override this method in order to produce a locale-specific message. For subclasses that do not override this method, the default implementation returns the same result as getMessage()."
– fool4jesus
Aug 31 '15 at 18:14
The documentation clearly says "Subclasses may override this method in order to produce a locale-specific message. For subclasses that do not override this method, the default implementation returns the same result as getMessage()."
– fool4jesus
Aug 31 '15 at 18:14
add a comment |
no. it definitely does not mean language specific implementations. it means implementations that use an internationalization (aka i18n) mechanism. see this page for more details of what resource bundles are and how to use them.
the gist is that you place any text in resource files, of which you have many (one per locale/language/etc) and your code uses a mechanism to look up the text in the correct resource file (the link i provided goes into details).
as to when and where this gets used, its entirely up to you. normally you'd only be concerned about this when you want to present an exception to a non-technical user, who may not know english that well. so for example, if you're just writing to log (which commonly only technical users read and so isnt a common i18n target) you'd do:
try {
somethingDangerous();
} catch (Exception e) {
log.error("got this: "+e.getMessage());
}
but if you intend to display the exception message to the screen (as a small dialogue, for example) then you might want to display the message in a local language:
try {
somethingDangerous();
} catch (Exception e) {
JOptionPane.showMessageDialog(frame,
e.getLocalizedMessage(),
"Error", <---- also best be taken from i18n
JOptionPane.ERROR_MESSAGE);
}
add a comment |
no. it definitely does not mean language specific implementations. it means implementations that use an internationalization (aka i18n) mechanism. see this page for more details of what resource bundles are and how to use them.
the gist is that you place any text in resource files, of which you have many (one per locale/language/etc) and your code uses a mechanism to look up the text in the correct resource file (the link i provided goes into details).
as to when and where this gets used, its entirely up to you. normally you'd only be concerned about this when you want to present an exception to a non-technical user, who may not know english that well. so for example, if you're just writing to log (which commonly only technical users read and so isnt a common i18n target) you'd do:
try {
somethingDangerous();
} catch (Exception e) {
log.error("got this: "+e.getMessage());
}
but if you intend to display the exception message to the screen (as a small dialogue, for example) then you might want to display the message in a local language:
try {
somethingDangerous();
} catch (Exception e) {
JOptionPane.showMessageDialog(frame,
e.getLocalizedMessage(),
"Error", <---- also best be taken from i18n
JOptionPane.ERROR_MESSAGE);
}
add a comment |
no. it definitely does not mean language specific implementations. it means implementations that use an internationalization (aka i18n) mechanism. see this page for more details of what resource bundles are and how to use them.
the gist is that you place any text in resource files, of which you have many (one per locale/language/etc) and your code uses a mechanism to look up the text in the correct resource file (the link i provided goes into details).
as to when and where this gets used, its entirely up to you. normally you'd only be concerned about this when you want to present an exception to a non-technical user, who may not know english that well. so for example, if you're just writing to log (which commonly only technical users read and so isnt a common i18n target) you'd do:
try {
somethingDangerous();
} catch (Exception e) {
log.error("got this: "+e.getMessage());
}
but if you intend to display the exception message to the screen (as a small dialogue, for example) then you might want to display the message in a local language:
try {
somethingDangerous();
} catch (Exception e) {
JOptionPane.showMessageDialog(frame,
e.getLocalizedMessage(),
"Error", <---- also best be taken from i18n
JOptionPane.ERROR_MESSAGE);
}
no. it definitely does not mean language specific implementations. it means implementations that use an internationalization (aka i18n) mechanism. see this page for more details of what resource bundles are and how to use them.
the gist is that you place any text in resource files, of which you have many (one per locale/language/etc) and your code uses a mechanism to look up the text in the correct resource file (the link i provided goes into details).
as to when and where this gets used, its entirely up to you. normally you'd only be concerned about this when you want to present an exception to a non-technical user, who may not know english that well. so for example, if you're just writing to log (which commonly only technical users read and so isnt a common i18n target) you'd do:
try {
somethingDangerous();
} catch (Exception e) {
log.error("got this: "+e.getMessage());
}
but if you intend to display the exception message to the screen (as a small dialogue, for example) then you might want to display the message in a local language:
try {
somethingDangerous();
} catch (Exception e) {
JOptionPane.showMessageDialog(frame,
e.getLocalizedMessage(),
"Error", <---- also best be taken from i18n
JOptionPane.ERROR_MESSAGE);
}
edited Jul 28 '14 at 4:44
answered Jul 28 '14 at 4:38
radairadai
18.6k75197
18.6k75197
add a comment |
add a comment |
public String getMessage()
Returns the detail message string of this throwable.
public String getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage()
.
In your case e is nothing but the object of exception ...
getLocalizedMessage()
u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
add a comment |
public String getMessage()
Returns the detail message string of this throwable.
public String getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage()
.
In your case e is nothing but the object of exception ...
getLocalizedMessage()
u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
add a comment |
public String getMessage()
Returns the detail message string of this throwable.
public String getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage()
.
In your case e is nothing but the object of exception ...
getLocalizedMessage()
u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
public String getMessage()
Returns the detail message string of this throwable.
public String getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage()
.
In your case e is nothing but the object of exception ...
getLocalizedMessage()
u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
edited Jul 28 '14 at 4:50


Lavekush Agrawal
4,39963774
4,39963774
answered Jul 28 '14 at 4:46


Umer KianiUmer Kiani
2,46352548
2,46352548
add a comment |
add a comment |
This is what the Throwable.java class have to say. Maybe it can help someone:
/**
* Returns the detail message string of this throwable.
*
* @return the detail message string of this {@code Throwable} instance
* (which may be {@code null}).
*/
public String getMessage() {
return detailMessage;
}
/**
* Creates a localized description of this throwable.
* Subclasses may override this method in order to produce a
* locale-specific message. For subclasses that do not override this
* method, the default implementation returns the same result as
* {@code getMessage()}.
*
* @return The localized description of this throwable.
* @since JDK1.1
*/
public String getLocalizedMessage() {
return getMessage();
}
add a comment |
This is what the Throwable.java class have to say. Maybe it can help someone:
/**
* Returns the detail message string of this throwable.
*
* @return the detail message string of this {@code Throwable} instance
* (which may be {@code null}).
*/
public String getMessage() {
return detailMessage;
}
/**
* Creates a localized description of this throwable.
* Subclasses may override this method in order to produce a
* locale-specific message. For subclasses that do not override this
* method, the default implementation returns the same result as
* {@code getMessage()}.
*
* @return The localized description of this throwable.
* @since JDK1.1
*/
public String getLocalizedMessage() {
return getMessage();
}
add a comment |
This is what the Throwable.java class have to say. Maybe it can help someone:
/**
* Returns the detail message string of this throwable.
*
* @return the detail message string of this {@code Throwable} instance
* (which may be {@code null}).
*/
public String getMessage() {
return detailMessage;
}
/**
* Creates a localized description of this throwable.
* Subclasses may override this method in order to produce a
* locale-specific message. For subclasses that do not override this
* method, the default implementation returns the same result as
* {@code getMessage()}.
*
* @return The localized description of this throwable.
* @since JDK1.1
*/
public String getLocalizedMessage() {
return getMessage();
}
This is what the Throwable.java class have to say. Maybe it can help someone:
/**
* Returns the detail message string of this throwable.
*
* @return the detail message string of this {@code Throwable} instance
* (which may be {@code null}).
*/
public String getMessage() {
return detailMessage;
}
/**
* Creates a localized description of this throwable.
* Subclasses may override this method in order to produce a
* locale-specific message. For subclasses that do not override this
* method, the default implementation returns the same result as
* {@code getMessage()}.
*
* @return The localized description of this throwable.
* @since JDK1.1
*/
public String getLocalizedMessage() {
return getMessage();
}
answered Mar 3 '17 at 11:53


sivisivi
6,60623640
6,60623640
add a comment |
add a comment |
To my understanding, getMessage returns the name of the exception. getLocalizedMessage returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage on must have overridden the getLocalizedMessage method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
So in most cases, the result will be the same but in some cases it will return the exception name in the language of the region where the program is being run.
Does that mean language specific implementations ? like if i use
e.getLocalizedMessage() for example my app in English - error will be
thrown in English , if i use my app in Spanish - then error will be
thrown in Spanish
public String
getMessage()
Returns the detail message string of this throwable.
public String
getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage().
In your case e is nothing but the object of exception ...
getLocalizedMessage() u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
Read more...
add a comment |
To my understanding, getMessage returns the name of the exception. getLocalizedMessage returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage on must have overridden the getLocalizedMessage method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
So in most cases, the result will be the same but in some cases it will return the exception name in the language of the region where the program is being run.
Does that mean language specific implementations ? like if i use
e.getLocalizedMessage() for example my app in English - error will be
thrown in English , if i use my app in Spanish - then error will be
thrown in Spanish
public String
getMessage()
Returns the detail message string of this throwable.
public String
getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage().
In your case e is nothing but the object of exception ...
getLocalizedMessage() u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
Read more...
add a comment |
To my understanding, getMessage returns the name of the exception. getLocalizedMessage returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage on must have overridden the getLocalizedMessage method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
So in most cases, the result will be the same but in some cases it will return the exception name in the language of the region where the program is being run.
Does that mean language specific implementations ? like if i use
e.getLocalizedMessage() for example my app in English - error will be
thrown in English , if i use my app in Spanish - then error will be
thrown in Spanish
public String
getMessage()
Returns the detail message string of this throwable.
public String
getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage().
In your case e is nothing but the object of exception ...
getLocalizedMessage() u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
Read more...
To my understanding, getMessage returns the name of the exception. getLocalizedMessage returns the name of the exception in the local language of the user (Chinese, Japanese etc.). In order to make this work, the class you are calling getLocalizedMessage on must have overridden the getLocalizedMessage method. If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage.
So in most cases, the result will be the same but in some cases it will return the exception name in the language of the region where the program is being run.
Does that mean language specific implementations ? like if i use
e.getLocalizedMessage() for example my app in English - error will be
thrown in English , if i use my app in Spanish - then error will be
thrown in Spanish
public String
getMessage()
Returns the detail message string of this throwable.
public String
getLocalizedMessage()
Creates a localized description of this throwable. Subclasses may
override this method in order to produce a locale-specific message. For
subclasses that do not override this method, the default implementation
returns the same result as getMessage().
In your case e is nothing but the object of exception ...
getLocalizedMessage() u need to override and give your own message i.e
the meaning for localized message.
For example ... if there is a null pointer exception ...
By printing e it will display null
e.getMessage() ---> NullPointerException
Read more...
edited Jul 28 '14 at 4:42
answered Jul 28 '14 at 4:38
Deepanshu J bediDeepanshu J bedi
1,4031723
1,4031723
add a comment |
add a comment |
To my understanding, getMessage
returns the name of the exception.
getLocalizedMessage
returns the name of the exception in the local language of the user (Chinese, Japanese etc.).
In order to make this work, the class you are calling getLocalizedMessage
on must have overridden the getLocalizedMessage
method.
If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage
.
add a comment |
To my understanding, getMessage
returns the name of the exception.
getLocalizedMessage
returns the name of the exception in the local language of the user (Chinese, Japanese etc.).
In order to make this work, the class you are calling getLocalizedMessage
on must have overridden the getLocalizedMessage
method.
If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage
.
add a comment |
To my understanding, getMessage
returns the name of the exception.
getLocalizedMessage
returns the name of the exception in the local language of the user (Chinese, Japanese etc.).
In order to make this work, the class you are calling getLocalizedMessage
on must have overridden the getLocalizedMessage
method.
If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage
.
To my understanding, getMessage
returns the name of the exception.
getLocalizedMessage
returns the name of the exception in the local language of the user (Chinese, Japanese etc.).
In order to make this work, the class you are calling getLocalizedMessage
on must have overridden the getLocalizedMessage
method.
If it hasn't, the method of one of it's super classes is called which by default just returns the result of getMessage
.
edited Jun 14 '18 at 3:36
Paul Rooney
12.7k72844
12.7k72844
answered Jul 28 '14 at 5:06
rahulrahul
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f24988491%2fdifference-between-e-getmessage-and-e-getlocalizedmessage%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Yes, it means locale (language, culture) specific implementations. What's wrong with official documentation?
– default locale
Jul 28 '14 at 4:38