1
\$\begingroup\$

I have a few custom exception classes that I created simply for the sake of having my own exception message:

public class DivideByZeroException extends Exception 
{   
   @Override
   public String toString()
   {
       return "ERROR: Expression cannot divide by 0";
   }
}

I realize that this can be done by throwing an exception like:

throw new Exception("ERROR: Expression cannot divide by 0");

but this contains a prefix of java.lang.Exception: in the string.

I think it's a bit ugly to remove the unwanted prefix from the string, but creating a class just for the exception message seems a bit excessive to me. Is there a different way to do this?

\$\endgroup\$

3 Answers 3

2
\$\begingroup\$

If you want all your exceptions to follow this style, then you could have one parent Exception class, then make your application exceptions extend it, like so:

class MyException extends Exception
{
    MyException(String message)
    {
        super(message);
    }

    @Override
    public String toString()
    {
        return "ERROR: " + this.getMessage();
    }
}

class DivideByZeroException extends MyException
{
    DivideByZeroException()
    {
        super("Expression cannot divide by 0");
    }
}

This way, you don't have to override toString() every time, and you also don't have to put "ERROR" into the actual text of the exception.

\$\endgroup\$
5
\$\begingroup\$

Don't throw raw Exceptions, use always a subclass (as explained by MrLore). If you are throwing raw exceptions you also have to catch them, which might mask other exception or runtime exceptions. You would add a instanceof to any of your catch blocks.

\$\endgroup\$
0
\$\begingroup\$

Even if it is already cleared by RHS, I am not quite sure what the original idea behind this question is.

I think it's a bit ugly to remove the unwanted prefix from the string, but creating a class just for the exception message seems a bit excessive to me. Is there a different way to do this?

Well, you do not have to remove the prefix? This is just some formating from Java. You could catch an Exception e and use e.getMessage() to see the message and do whatever you want with it.

Nevertheless, you should avoid implementing your own Exception class. And you should not throw a generic "Exception" (See for example Effective Java Programming Language Guide). Just use the current available exceptions from Java, most likely IllegalArgumentException or IllegalStateExceptions. This covers about 90% of all valid cases in typical code (own experience).

\$\endgroup\$
3
  • \$\begingroup\$ java.lang.ArithmeticException :) \$\endgroup\$ Commented Jan 22, 2013 at 5:54
  • \$\begingroup\$ @mnhg example for an use case? I think, this could be handled most of the time by Argument/State, too. \$\endgroup\$
    – tb-
    Commented Jan 23, 2013 at 14:16
  • \$\begingroup\$ I only wanted to state, that this is also a standard exception, and actually it is designed for exactly this scenario. (Ex.: dividing by zero, dividing and loosing scale information, overflows in multiplication, ...) \$\endgroup\$ Commented Jan 25, 2013 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.