They are probably doing so because of naming conflicts. I assume that you cannot have two methods named getEntity, one which possibly throws an exception and one which returns null. Therefore, you have to name them accordingly.

I, for one, dislike the practice of having many different ways of calling the same method unless it is performing some alteration that only that particular class can perform.

In other words, if getValueOrNull is simply calling getValueOrException, capturing the exception, and in that case returning null, this can be performed by the caller. It clutters the class with methods that don't really contribute anything useful. Rather I would prefer the getValue, and know that it throws the exception. Better still, I would prefer to know that all get methods potentially throw exceptions, and none of them return null instead so that behavior is uniform throughout my project, or inversely, all return null, and know that the caller would have to throw an exception if that were desired.

However, it is also true that you're not in charge of that. My advice is to bring it up, but don't sweat the petty things. Ultimately, the responsibility of such naming conventions falls on their shoulders, regardless of whether or not they take your advice, and because it is their asses on the line, I believe it is their prerogative to say no, in my humble opinion.

They are probably doing so because of naming conflicts. I assume that you cannot have two methods named getEntity, one which possibly throws an exception and one which returns null. Therefore, you have to name them accordingly.

I, for one, dislike the practice of having many different ways of calling the same method unless it is performing some alteration that only that particular class can perform.

In other words, if getValueOrNull is simply calling getValueOrException, capturing the exception, and in that case returning null, this can be performed by the caller. It clutters the class with methods that don't really contribute anything useful. Rather I would prefer the getValue, and know that it throws the exception. Better still, I would prefer to know that all get methods potentially throw exceptions, and none of them return null instead so that behavior is uniform throughout my project, or inversely, all potentially return null, and know that the caller would have to throw an exception if that were desired.

However, it is also true that you're not in charge of that. My advice is to bring it up, but don't sweat the petty things. Ultimately, the responsibility of such naming conventions falls on their shoulders, regardless of whether or not they take your advice, and because it is their asses on the line, I believe it is their prerogative to say no, in my humble opinion.

They are probably doing so because of naming conflicts. I assume that you cannot have two methods named getEntity, one which possibly throws an exception and one which returns null. Therefore, you have to name them accordingly.

I, for one, dislike the practice of having many different ways of calling the same method unless it is performing some alteration that only that particular class can perform.

In other words, if getValueOrNull is simply calling getValueOrException, capturing the exception, and in that case returning null, this can be performed by the caller. It clutters the class with methods that don't really contribute anything useful. Rather I would prefer the getValue, and know that it throws the exception. Better still, I would prefer to know that all get methods potentially throw exceptions, and none of them return null instead so that behavior is uniform throughout my project, or inversely, all return null, and know that the caller would have to throw an exception if that were desired.

However, it is also true that you're not in charge of that. My advice is to bring it up, but don't sweat the petty things. Ultimately, the responsibility of such naming conventions falls on their shoulders, regardless of whether or not they take your advice or not, therefore it is their perogative to say no, in my humble opinion.

They are probably doing so because of naming conflicts. I assume that you cannot have two methods named getEntity, one which possibly throws an exception and one which returns null. Therefore, you have to name them accordingly.

I, for one, dislike the practice of having many different ways of calling the same method unless it is performing some alteration that only that particular class can perform.

In other words, if getValueOrNull is simply calling getValueOrException, capturing the exception, and in that case returning null, this can be performed by the caller. It clutters the class with methods that don't really contribute anything useful. Rather I would prefer the getValue, and know that it throws the exception. Better still, I would prefer to know that all get methods potentially throw exceptions, and none of them return null instead so that behavior is uniform throughout my project, or inversely, all return null, and know that the caller would have to throw an exception if that were desired.

However, it is also true that you're not in charge of that. My advice is to bring it up, but don't sweat the petty things. Ultimately, the responsibility of such naming conventions falls on their shoulders, regardless of whether or not they take your advice, and because it is their asses on the line, I believe it is their prerogative to say no, in my humble opinion.