User defined exceptions: when do we use them? What

Question

I'm sure that this question has been addressed in many best practices books, but still... Most of the times I see examples of wrong usage of custom exceptions, therefore I was wondering what would be a good situation to use them?

In particular, at the moment I'm working on a type checker for a compilers course.Therefore, I have a SymbolTable class, which is rather similar to a Map.The key difference from your ordinary map is that each symbol has to be defined at most once, so a put(String, Object) operation should fail if the key we're trying to insert is already present in the SymbolTable.

So here's the question: whenever we try to insert a key, and that key already exists in the SymbolTable, how should the SymbolTable behave? Should we have a

boolean insert(String key, Object value);

method that returns "false" in case the insert fails?Or should we rather use an insert method that has a return value "void" and throws an exception when a duplicate value is encountered?

Thanks in advance:)

Answer 1

Exceptions should be throw on exceptional cases.

In that particular case, for example, if method is named insert() I would treat an already on the list key as a normal case and update it.

Moreover, although exceptions shouldn't be used to control the code flow, return booleans indicating failure/success isn't the better option either(there can be many cases for failure and False indicates nothing on the matter).

Bottom line, I would do something line this:

// Failures can happen 
void add(key, value) throws AlreadyOnMapException

// Update if already on list
void insert(key, value);

// Make available Contains() methods to control the flow by avoiding exceptions
boolean containsKey(key);

boolean containsValue(value);

Answer 2

Deciding whether to use an exception or a return value is a balance of several "forces":

• The caller can ignore a return value and continue with the next line, but it can't ignore an exception. Exceptions tend to be used in cases where ignoring the problem and continuing could lead to a bigger problem.
• Exceptions impose a burden on the caller because the code to handle them is more complex than just checking a return value. So they're often avoided when a simple return value would suffice.
• On the other hand, exceptions can relieve the immediate caller of the burden of checking the result, because it can just trust that if something goes wrong, the stack will be unwound to a catch block somewhere else.
• Exception handling is more complex than ordinary return, so there's a performance hit if they're thrown frequently. Exceptions are generally used for situations that aren't expected to happen frequently.
• When the error information and the "normal" result are of different types, throwing an exception is generally better than shoehorning unrelated things into the same return value (e.g. making the method return Object so that it can return either a string or a number).

In your example of a symbol table, I'd probably just return false since it's likely to make the code simpler, but either could be reasonable, depending on the design of the rest of your program.

Answer 3

It really depends on what you decide is expected to occur. Using your insert example, is it expected that there is a duplicate, or would it be abnormal for there to be a duplicate? If the situation is abnormal (i.e. something that normally shouldn't happen) then it is exceptional.

What you shouldn't do is use exceptions for flow control. If, say 10% of the time it is expected that there be a duplicate, then using an exception would be ineffective. But if it is an error on the part of the programmer (i.e. an unexpected action) to put a duplicate in when it shouldn't be put in, then perhaps an exception is appropriate.

This has been discussed to death though, try searching around a bit.

Answer 4

User defined exceptions: when do we use them?

I am sure there are very well defined scenarios where to use custom based exceptions in many books. However recently I observed an interesting use of custom based exceptions i.e to improve logging. eg function of Class A call function of Class B and function of Class B calls function of Class C and all of these functions can throw IO Exception. so if IO Exception comes in Class C function, catch that exception, log it, now make object of custom based exception and throw that object. every calling function would be catching custom based exception along with other exceptions, and whenever they catch custom based exception they DO NOT log it coz it will be redundant and they simply throw it back.