[ACCEPTED]-Is there a particular naming convention for Java methods that throw exceptions?-method-names

Yes, you name them the same as methods that 5 don't.

Isn't the exception specification 4 enough?

Edit: If you have similar methods 3 that throw/not throw, I recommend the Parse/TryParse pattern 2 (Parse being replaced by the operation). .NET 1 Framework uses it frequently (Dictionary<T,K>.TryGetValue, Monitor.TryEnter, int.TryParse, etc. etc.).

Edit: Coding Horror: TryParse and the Exception Tax

Don't do that.

This is like asking "is there 15 a naming convention for methods that take 14 two Strings as parameters".

Java has checked 13 exceptions, which means that you need to 12 declare them anyway. So you can easily see 11 if an exception will be thrown, and what 10 type of exception. You cannot even compile 9 code that calls the method without adding 8 exception handling code.

Update: It seems your intention 7 is to have methods that check if a certain 6 condition is true, but you do not want to 5 return just false, but throw an Exception 4 if the condition is not met, so that you 3 can also convey an explanation message (in 2 the Exception). I think a prefix of "assert" or 1 "ensure" makes sense:

 // instead of
 if (! isAuthenticated())
    throw new NotAuthenticatedException("not sure why at this point...");

 // you do
 assertAuthentication();
 // which will throw NotAuthenticatedException("proper explanation") inside

Why would you do such a thing in Java? It 6 already has exception specifiers built into 5 the language. The compiler will prevent 4 you from calling a method which explicitly 3 throws an exception without some action 2 being taken on your part to handle or allow 1 the exception to propagate?

If you need these methods differentiated, I'm 9 sure you can do it in the naming without using 8 a suffix or anything, which is (as others 7 have pointed out) pretty ghastly.

Why have:

boolean authenticate(String username, String password);

and 6 (say)

void authenticateEx(String username, String password) throws WhateverException;

when you could actually make it a meaningful 5 part of the name by conveying the actual 4 intent:

void ensureCanAuthenticate(String username, String password);

// or

void assertValidCredentials(...);

// or

void authenticateOrDie(...);

... or any number of other (probably 3 better) names which actually convey the 2 intent rather than relying on a confusing 1 suffix.

Exceptions are part of the method signature 2 in Java, therefore such a naming convention 1 would be redundant.

Hungarian notation for methods that throw 10 exceptions? Quel horror!

Do you mean checked 9 or unchecked exceptions? Why on earth would 8 you want to do that?

When you think about 7 it, you'd have to add your convention to 6 every method, because there's always the 5 potential of an error or NPE or some other 4 thing that could go wrong.

The "throws" clause 3 is enough when you have checked exceptions, and 2 there's no good purpose on God's green earth 1 for unchecked exceptions.

Don't do it. Please.

There is no convention and adding an ex 22 will make the name harder to read and ugly 21 looking for the average java programmer.

But 20 at sometimes I could imagine that it would 19 make your code faster understandable to 18 add a try to methods that are likely to 17 throw an exception. Especially if they are 16 unchecked.

It doesn't have to be something 15 ugly like it could be found in many c/c++ programs 14 where you use _name or mName for members 13 or iValue for integers. But in java there 12 are some conventions too. If a method will 11 return an integer it is prefixed with is... set, get 10 and test are the most used examples for 9 this. All of this things are documented 8 in the method header, through return type 7 annotations etc... But adding one word to 6 the function name makes it easier and faster 5 to read and understand.

Why not use try to 4 give programmers reading your code a subconscious 3 hint that this method is likely to throw 2 an exception. Like tryCopyFile instead of 1 tryWriteFile.

There is none that I'm aware of.

In my opinion, the 3 only time something like that makes sense 2 is in unit test cases (e.g., testFooExpectingException()). But 1 that's not really what you're talking about.

There is no such convention because every 7 method can throw exceptions, regardless 6 of whether you declare them or not. It's 5 also somewhat redundant in this day and 4 age of IDE tooltips (unless you're not using 3 an IDE of course).

I'm curious to know why 2 you are tempted to use such a naming convention 1 though.

Every once in a while you'll run into a 21 case where it might make sense to have a 20 method name like getSafely() (returns a default value 19 in the case where the actual value is invalid, for 18 code that doesn't care too much about real 17 values vs placeholders) or its converse 16 getOrBlowUp() (for fail-fast code where a missing value 15 is technically possible but indicates a 14 bug in the code that's supposed to set the 13 value).

But the point here isn't "method 12 2 throws an exception, method 1 doesn't" -- because, as 11 mentioned above, any code could throw a RuntimeException. The 10 point is that the two methods have different 9 error-handling semantics, specific to different 8 use cases, and that's what the method names try 7 to capture.

Even then, the code would usually 6 be cleaner if you could just get away with 5 one behavior or the other, and call the 4 method get().

A useful parallel here might be 3 the distinction between Systems Hungarian and Apps Hungarian in Hungarian Notation. (See also this piece on coding conventions from 2 Joel on Software.)

• Systems Hungarian just tells you the type of the variable, so integer count becomes iCount. This is the most common form of Hungarian notation and IMHO it's (1) pretty pointless with a modern IDE and (2) potentially deceptive, if someone changes the type declaration without renaming the variable.
• Apps Hungarian tells you the purpose of the variable, so integer (or short, or ordinal ID object, or whatever, who cares?) index representing a data row becomes drIndex, and index representing an annotation column becomes acIndex. This is much more useful and much less likely to cause trouble.

Calling your method getEx() is 1 Systems Hungarian.

Generally don't add it to method names.

Add 2 throws instead.

int parseInt(String s, int radix) throws NumberFormatException

But personally i like for 1 getter e.g.

    getFieldsOrThrow(java.lang.String key)
    getFieldsOrDefault(java.lang.String key, Value defaultValue)

https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Struct