3 Improved formatting of copied comment.
source | link

My suggestion is do one of this:

1. Use the QueryResult object but change the name of QueryResult.ReasonForNoValue() to QueryResult.Message().

public class QueryResult
{
    public TValue Value { get; private set; }
    public TMessage Message { get; private set; }
}

2. Rise KeyUnknowException or NoTranslationException, although you already said you don't like this solution.

3. Always return a non-null value. Only that two special string values exist: "#UKNOWN_KEY" and "#NO_TRANSLATION".

EDIT: (thanx to @DanielHilgarth  ) You would need to document several things: (1) That a missing value doesn't return null but still a string. (2) That a missing value is indicated by several magic strings (with the same implications as magic constants). (3) What each of those magic strings means.

  1. That a missing value doesn't return null but still a string.
  2. That a missing value is indicated by several magic strings (with the same implications as magic constants).
  3. What each of those magic strings means.

And finally, someone would have to actually read that documentation. In
In general, you increase the possibility of bugs with this kind of architecture increases the possibility of bugs.

My suggestion is do one of this:

1. Use the QueryResult object but change the name of QueryResult.ReasonForNoValue() to QueryResult.Message().

public class QueryResult
{
    public TValue Value { get; private set; }
    public TMessage Message { get; private set; }
}

2. Rise KeyUnknowException or NoTranslationException, although you already said you don't like this solution.

3. Always return a non-null value. Only that two special string values exist: "#UKNOWN_KEY" and "#NO_TRANSLATION".

EDIT: (thanx to @DanielHilgarth  ) You would need to document several things: (1) That a missing value doesn't return null but still a string. (2) That a missing value is indicated by several magic strings (with the same implications as magic constants). (3) What each of those magic strings means. And finally, someone would have to actually read that documentation. In general, you increase the possibility of bugs with this kind of architecture.

My suggestion is do one of this:

1. Use the QueryResult object but change the name of QueryResult.ReasonForNoValue() to QueryResult.Message().

public class QueryResult
{
    public TValue Value { get; private set; }
    public TMessage Message { get; private set; }
}

2. Rise KeyUnknowException or NoTranslationException, although you already said you don't like this solution.

3. Always return a non-null value. Only that two special string values exist: "#UKNOWN_KEY" and "#NO_TRANSLATION".

EDIT: (thanx to @DanielHilgarth) You would need to document several things:

  1. That a missing value doesn't return null but still a string.
  2. That a missing value is indicated by several magic strings (with the same implications as magic constants).
  3. What each of those magic strings means.

And finally, someone would have to actually read that documentation.
In general, this kind of architecture increases the possibility of bugs.

2 improved, added a third opcion
source | link

My suggestion is do one of this:

1. Use the QueryResult object but change the name of QueryResult.ReasonForNoValue() to QueryResult.Message().

public class QueryResult
{
    public TValue Value { get; private set; }
    public TMessage Message { get; private set; }
}

2. Rise KeyUnknowException or NoTranslationException, although you already said you don't like this solution.

3. Always return a non-null value. Only that two special string values exist: "#UKNOWN_KEY" and "#NO_TRANSLATION".

2. Rise KeyUnknowException or NoTranslationException EDIT: (thanx to @DanielHilgarth ) You would need to document several things: (1) That a missing value doesn't return null but still a string. (2) That a missing value is indicated by several magic strings (with the same implications as magic constants). (3) What each of those magic strings means. And finally, although you already saidsomeone would have to actually read that documentation. In general, you don't likeincrease the possibility of bugs with this solutionkind of architecture.

My suggestion is do one of this:

1. Always return a non-null value. Only that two special string values exist: "#UKNOWN_KEY" and "#NO_TRANSLATION".

2. Rise KeyUnknowException or NoTranslationException, although you already said you don't like this solution.

My suggestion is do one of this:

1. Use the QueryResult object but change the name of QueryResult.ReasonForNoValue() to QueryResult.Message().

public class QueryResult
{
    public TValue Value { get; private set; }
    public TMessage Message { get; private set; }
}

2. Rise KeyUnknowException or NoTranslationException, although you already said you don't like this solution.

3. Always return a non-null value. Only that two special string values exist: "#UKNOWN_KEY" and "#NO_TRANSLATION".

EDIT: (thanx to @DanielHilgarth ) You would need to document several things: (1) That a missing value doesn't return null but still a string. (2) That a missing value is indicated by several magic strings (with the same implications as magic constants). (3) What each of those magic strings means. And finally, someone would have to actually read that documentation. In general, you increase the possibility of bugs with this kind of architecture.

1
source | link

My suggestion is do one of this:

1. Always return a non-null value. Only that two special string values exist: "#UKNOWN_KEY" and "#NO_TRANSLATION".

2. Rise KeyUnknowException or NoTranslationException, although you already said you don't like this solution.