Return to Question

When designing exceptions should I write messages that a user or a developer should understand? Who should actually be the reader of exception messages?

I find exception messages aren't useful at all and I always have a hard time writing them. By convention the type of the exception should already tell us why something didn't work and custom properties might add even more information like file names, indexes, keys etc. so why repeating it in the message itself? An autogenerated message could also do and all what it had to contain is the name of the exception with a list of additional properties. This would be exactly as useful as a handwritten text.

Wouldn't it be better to not write messages at all but instead have special exception renderers that takes care of creating meaningful messages maybe in different languages rather then hardcoding them in code?

I've been asked whether either of those questions provide an answer to my question:

• How to write a good exception message
• Why do many exception messages not contain useful details?

I've read them both and I wasn't happy with their answers. They talk about users in general and focus on the content of the message itself rather then on the addressee and it turns out there can be at least two of them: the end-user and the developer. I never know which one I should speak to when writing exception messages.

I even think that the famous message doesn't have any real value at all as it just repeats the name of the exception type in different words so why bother writing them at all? I can perfectly generate them automatically.

To me exception message lacks a differentiation of its readers. A perfect exception would need to provide at least two versions of the message: one for the end-user and one for the developer. Calling it just a message is too generic. A developer message should be then written in English but the end-user's message might need to be translated into other languages. It is not possible to achieve all this with only one message so an exception would need to provide some identifier to the end-user message that as I just said, might be available in different languages.

When I read all the other linked questions I get the impression that an exception message is indeed intended to be read by an end-user and not a developer... a single message is like to have a cake and eat it too.

When designing exceptions should I write messages that a user or a developer should understand? Who should actually be the reader of exception messages?

I find exception messages aren't useful at all and I always have a hard time writing them. By convention the type of the exception should already tell us why something didn't work and custom properties might add even more information like file names, indexes, keys etc. so why repeating it in the message itself? An autogenerated message could also do and all what it had to contain is the name of the exception with a list of additional properties. This would be exactly as useful as a handwritten text.

Wouldn't it be better to not write messages at all but instead have special exception renderers that takes care of creating meaningful messages maybe in different languages rather then hardcoding them in code?

I've been asked whether either of those questions provide an answer to my question:

• How to write a good exception message
• Why do many exception messages not contain useful details?

I've read them both and I wasn't happy with their answers. They talk about users in general and focus on the content of the message itself rather then on the addressee and it turns out there can be at least two of them: the end-user and the developer. I never know which one I should speak to when writing exception messages.

I even think that the famous message doesn't have any real value at all as it just repeats the name of the exception type in different words so why bother writing them at all? I can perfectly generate them automatically.

To me exception message lacks a differentiation of its readers. A perfect exception would need to provide at least two versions of the message: one for the end-user and one for the developer. Calling it just a message is too generic. A developer message should be then written in English but the end-user's message might need to be translated into other languages. It is not possible to achieve all this with only one message so an exception would need to provide some identifier to the end-user message that as I just said, might be available in different languages.

When I read all the other linked questions I get the impression that an exception message is indeed intended to be read by an end-user and not a developer... a single message is like to have a cake and eat it too.

When designing exceptions should I write messages that a user or a developer should understand? Who should actually be the reader of exception messages?

I find exception messages aren't useful at all and I always have a hard time writing them. By convention the type of the exception should already tell us why something didn't work and custom properties might add even more information like file names, indexes, keys etc. so why repeating it in the message itself? An autogenerated message could also do and all what it had to contain is the name of the exception with a list of additional properties. This would be exactly as useful as a handwritten text.

Wouldn't it be better to not write messages at all but instead have special exception renderers that takes care of creating meaningful messages maybe in different languages rather then hardcoding them in code?

I've been asked whether either of those questions provide an answer to my question:

• How to write a good exception message
• Why do many exception messages not contain useful details?

I've read them both and I wasn't happy with their answers. They talk about users in general and focus on the content of the message itself rather then on the addressee and it turns out there can be at least two of them: the end-user and the developer. I never know which one I should speak to when writing exception messages.

I even think that the famous message doesn't have any real value at all as it just repeats the name of the exception type in different words so why bother writing them at all? I can perfectly generate them automatically.

To me exception message lacks a differentiation of its readers. A perfect exception would need to provide at least two versions of the message: one for the end-user and one for the developer. Calling it just a message is too generic. A developer message should be then written in English but the end-user's message might need to be translated into other languages. It is not possible to achieve all this with only one message so an exception would need to provide some identifier to the end-user message that as I just said, might be available in different languages.

When I read all the other linked questions I get the impression that an exception message is indeed intended to be read by an end-user and not a developer... a single message is like to have a cake and eat it too.

##Disclaimer

as to:

This question has been asked before and already has an answer. If those answers do not fully address your question, please edit this question to explain how it is different or ask a new question.

This question has not been asked before and didn't have an answer. It's a great pity that this question has been closed and that the community apparently didn't read the other one but probably based their judgement on the topic itself :-( and decided to mark it as duplicate although the linked question What layer to introduce human readable error messages? has nothing in common with this one. It's even off-topic for its own question. Did anyone read it? It's about some webservices and error codes and the actual description is about something completely different then the question itself.

When designing exceptions should I write messages that a user or a developer should understand? Who should actually be the reader of exception messages?

I find exception messages aren't useful at all and I always have a hard time writing them. By convention the type of the exception should already tell us why something didn't work and custom properties might add even more information like file names, indexes, keys etc. so why repeating it in the message itself? An autogenerated message could also do and all what it had to contain is the name of the exception with a list of additional properties. This would be exactly as useful as a handwritten text.

Wouldn't it be better to not write messages at all but instead have special exception renderers that takes care of creating meaningful messages maybe in different languages rather then hardcoding them in code?

I've been asked whether either of those questions provide an answer to my question:

• How to write a good exception message
• Why do many exception messages not contain useful details?

I've read them both and I wasn't happy with their answers. They talk about users in general and focus on the content of the message itself rather then on the addressee and it turns out there can be at least two of them: the end-user and the developer. I never know which one I should speak to when writing exception messages.

I even think that the famous message doesn't have any real value at all as it just repeats the name of the exception type in different words so why bother writing them at all? I can perfectly generate them automatically.

To me exception message lacks a differentiation of its readers. A perfect exception would need to provide at least two versions of the message: one for the end-user and one for the developer. Calling it just a message is too generic. A developer message should be then written in English but the end-user's message might need to be translated into other languages. It is not possible to achieve all this with only one message so an exception would need to provide some identifier to the end-user message that as I just said, might be available in different languages.

When I read all the other linked questions I get the impression that an exception message is indeed intended to be read by an end-user and not a developer... a single message is like to have a cake and eat it too.

When designing exceptions should I write messages that a user or a developer should understand? Who should actually be the reader of exception messages?

I find exception messages aren't useful at all and I always have a hard time writing them. By convention the type of the exception should already tell us why something didn't work and custom properties might add even more information like file names, indexes, keys etc. so why repeating it in the message itself? An autogenerated message could also do and all what it had to contain is the name of the exception with a list of additional properties. This would be exacly as useful as a handwirtten text.

Wouldn't it be better to not write messages at all but instead have special exception renderers that takes care of creating meaningful messages maybe in different languages rather then hardcoding them in code?

I've been asked whether either of those questions provide an answer to my question:

• How to write a good exception message
• Why do many exception messages not contain useful details?

I've read them both and I wasn't happy with their answers. They talk about users in general and focus on the content of the message itself rather then on the addressee and it turns out there can be at least two of them: the end-user and the developer. I never know which one I should speak to when writing execption messages.

I even think that the famous message doesn't have any real value at all as it just repeats the name of the exception type in different words so why bother writing them at all? I can perfectly generate them automatically.

To me exception message lacks a differentiation of its readers. A perfect exception would need to provide at least two versions of the message: one for the end-user and one for the developer. Calling it just a message is too generic. A developer message should be then written in english but the end-user's message might need to be translated into other languages. It is not possible to achieve all this with only one message so an exeption would need to provide some identifier to the end-user message that as I just said, might be available in different languages.

Whean I read all the other linked questions I get the impression that an exception message is indeed intended to be read by an end-user and not a developer... a single message is like to have a cake and eat it too.

##Desclimer

as to:

This question has been asked before and already has an answer. If those answers do not fully address your question, please edit this question to explain how it is different or ask a new question.

This question has not been asked before and didn't have an answer. It's a great pity that this question has been closed and that the community apparently didn't read the other one but probably based their judgement on the topic itself :-( and decided to mark it as duplicate although the linked question What layer to introduce human readable error messages? has nothing in common with this one. It's even off-topic for its own question. Did anyone read it? It's about some webservices and error codes and the actual description is about something copletely different then the question itself.

When designing exceptions should I write messages that a user or a developer should understand? Who should actually be the reader of exception messages?

I find exception messages aren't useful at all and I always have a hard time writing them. By convention the type of the exception should already tell us why something didn't work and custom properties might add even more information like file names, indexes, keys etc. so why repeating it in the message itself? An autogenerated message could also do and all what it had to contain is the name of the exception with a list of additional properties. This would be exactly as useful as a handwritten text.

Wouldn't it be better to not write messages at all but instead have special exception renderers that takes care of creating meaningful messages maybe in different languages rather then hardcoding them in code?

I've been asked whether either of those questions provide an answer to my question:

• How to write a good exception message
• Why do many exception messages not contain useful details?

I've read them both and I wasn't happy with their answers. They talk about users in general and focus on the content of the message itself rather then on the addressee and it turns out there can be at least two of them: the end-user and the developer. I never know which one I should speak to when writing exception messages.

I even think that the famous message doesn't have any real value at all as it just repeats the name of the exception type in different words so why bother writing them at all? I can perfectly generate them automatically.

To me exception message lacks a differentiation of its readers. A perfect exception would need to provide at least two versions of the message: one for the end-user and one for the developer. Calling it just a message is too generic. A developer message should be then written in English but the end-user's message might need to be translated into other languages. It is not possible to achieve all this with only one message so an exception would need to provide some identifier to the end-user message that as I just said, might be available in different languages.

When I read all the other linked questions I get the impression that an exception message is indeed intended to be read by an end-user and not a developer... a single message is like to have a cake and eat it too.

##Disclaimer

as to:

This question has been asked before and already has an answer. If those answers do not fully address your question, please edit this question to explain how it is different or ask a new question.

This question has not been asked before and didn't have an answer. It's a great pity that this question has been closed and that the community apparently didn't read the other one but probably based their judgement on the topic itself :-( and decided to mark it as duplicate although the linked question What layer to introduce human readable error messages? has nothing in common with this one. It's even off-topic for its own question. Did anyone read it? It's about some webservices and error codes and the actual description is about something completely different then the question itself.