When is a good time to create a custom Exception class rather thanusing IllegalArgumentException mos

Discussion in 'Java' started by -, Jul 12, 2005.

  1. -

    - Guest

    I always use IllegalArgumentException when the parameter suplied is invalid.

    When is a good time to create a custom Exception class rather than using
    IllegalArgumentException?
     
    -, Jul 12, 2005
    #1
    1. Advertising

  2. Re: When is a good time to create a custom Exception class ratherthan using IllegalArgumentException most of the time?

    - wrote:
    > I always use IllegalArgumentException when the parameter suplied is
    > invalid.
    >
    > When is a good time to create a custom Exception class rather than using
    > IllegalArgumentException?


    in my opinion as soon as possible, so that you can check the exceptions
    thrown and have a consistent exception handling mechanism in your code.
     
    Andrea Desole, Jul 12, 2005
    #2
    1. Advertising

  3. -

    Wibble Guest

    Re: When is a good time to create a custom Exception class ratherthan using IllegalArgumentException most of the time?

    Andrea Desole wrote:
    >
    >
    > - wrote:
    >
    >> I always use IllegalArgumentException when the parameter suplied is
    >> invalid.
    >>
    >> When is a good time to create a custom Exception class rather than
    >> using IllegalArgumentException?

    >
    >
    > in my opinion as soon as possible, so that you can check the exceptions
    > thrown and have a consistent exception handling mechanism in your code.

    Unless your doing special handling with particular bad arguments, IAE is
    good enough. IAE indicates a programming error, so the only correct way
    to deal with it is to fix your code, not do something cute at runtime.

    Its not useful to clutter your code with classes that add no value.
     
    Wibble, Jul 12, 2005
    #3
  4. Re: When is a good time to create a custom Exception class ratherthan using IllegalArgumentException most of the time?

    Wibble wrote:
    > Unless your doing special handling with particular bad arguments, IAE is
    > good enough. IAE indicates a programming error, so the only correct way
    > to deal with it is to fix your code, not do something cute at runtime.


    most of the exception classes indicate a programming error. Including,
    usually, your own

    >
    > Its not useful to clutter your code with classes that add no value.


    maybe not (it depends on the cases), but the point with runtime
    exceptions is that they are not checked. Here is something from the
    tutorial:

    http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

    At the end, if really new exception classes add no value, you can just
    make one. It's not a big overhead.
    I just find it good practice
     
    Andrea Desole, Jul 12, 2005
    #4
  5. -

    Guest

    Re: When is a good time to create a custom Exception class rather than using IllegalArgumentException most of the time?

    - <> wrote in message news:<42d34b8c$>...
    > I always use IllegalArgumentException when the parameter suplied is invalid.
    >
    > When is a good time to create a custom Exception class rather than using
    > IllegalArgumentException?


    An IllegalArgumentException, as you know, is a runtime exception,
    i.e., you don't reasonably expect that your client can do anything to
    recover from it.

    So a good time to create a custom Exception class rather than using
    IllegalArgumentException is to handle an argument from whose
    illegality you do reasonably expect that your client can recover.

    ..ed

    --
    www.EdmundKirwan.com - Home of The Fractal Class Composition.
     
    , Jul 12, 2005
    #5
  6. -

    Chris Smith Guest

    Re: When is a good time to create a custom Exception class rather than using IllegalArgumentException most of the time?

    Andrea Desole <> wrote:
    > At the end, if really new exception classes add no value, you can just
    > make one. It's not a big overhead. I just find it good practice


    The problem is that custom exception classes don't just add no value;
    they cause problems. Reasonably experienced Java programmers are
    familiar with IllegalArgumentException, and they know what it means and
    what it's used for. Your own exception may seem somewhat innocuous...
    but if vendors of three dozen third-party libraries all do as you
    suggest then the result can be a royal pain to deal with.

    This is especially true if, as you seem to suggest, the new exception
    classes are checked exceptions. There is no good reason to throw a
    checked exception in response to a programming error. It's just not a
    good decision, regardless of how difficult it is.

    As always, the answer here depends on the context. It's ridiculous to
    give unqualified advice to someone to declare their own exception class
    without even knowing the nature of the condition they want to respond
    to. It's equally ridiculous to never write new exception classes.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Jul 12, 2005
    #6
  7. Re: When is a good time to create a custom Exception class ratherthan using IllegalArgumentException most of the time?

    Chris Smith wrote:
    >
    > The problem is that custom exception classes don't just add no value;
    > they cause problems. Reasonably experienced Java programmers are
    > familiar with IllegalArgumentException, and they know what it means and
    > what it's used for. Your own exception may seem somewhat innocuous...
    > but if vendors of three dozen third-party libraries all do as you
    > suggest then the result can be a royal pain to deal with.


    three dozen third party libraries? Quite a lot

    >
    > This is especially true if, as you seem to suggest, the new exception
    > classes are checked exceptions. There is no good reason to throw a
    > checked exception in response to a programming error. It's just not a
    > good decision, regardless of how difficult it is.


    just because it's a programming error doesn't mean that you can't
    recovery from it, or you can't handle it.

    >
    > As always, the answer here depends on the context. It's ridiculous to
    > give unqualified advice to someone to declare their own exception class
    > without even knowing the nature of the condition they want to respond
    > to. It's equally ridiculous to never write new exception classes.
    >


    Okay, then your qualified advice is welcome.
    Agreed on the dependency on the context
     
    Andrea Desole, Jul 12, 2005
    #7
  8. -

    Daniel Dyer Guest

    Re: When is a good time to create a custom Exception class rather than using IllegalArgumentException most of the time?

    On Tue, 12 Jul 2005 15:56:22 +0100, Andrea Desole
    <> wrote:
    > Chris Smith wrote:
    >> This is especially true if, as you seem to suggest, the new exception
    >> classes are checked exceptions. There is no good reason to throw a
    >> checked exception in response to a programming error. It's just not a
    >> good decision, regardless of how difficult it is.

    >
    > just because it's a programming error doesn't mean that you can't
    > recovery from it, or you can't handle it.


    Can you provide an example where it would make sense to handle/recover
    from a programming error? If the program is broken fix it. Writing logic
    to recover from a bug elsewhere in the program seems counter-productive.
    If the argument is illegal, change the code so that it provides a valid
    argument. Writing an exception handler that somehow forces the program to
    continue will only lead to fragile software.

    These "programming errors" are where the programmer failed to express
    their intentions correctly in source code. Part of the program does not
    work as it was intended to. If the intention of the program is not clear
    it is unreasonable to expect the program to work correctly.

    Can you imagine how frustrating it would be if exceptions like
    IllegalArgumentException, ArrayIndexOutOfBoundsException and
    ArithmeticExcepion were checked exceptions? Every array access would have
    to be within a try...catch block, just in case you stuffed up with the
    indexing. Every division would have to explicitly deal with the
    possibility of division by zero (even if you can be certain that the
    divisor is non-zero). And if your IllegalArgumentException was checked,
    your method/constructor could be documented as follows:

    1). Please provide valid arguments.
    2). Please provide code to deal with your inability to follow the first
    instruction.


    Dan.


    --
    Daniel Dyer
    http://www.dandyer.co.uk
     
    Daniel Dyer, Jul 12, 2005
    #8
  9. Re: When is a good time to create a custom Exception class ratherthan using IllegalArgumentException most of the time?

    Daniel Dyer wrote:
    >
    > Can you provide an example where it would make sense to handle/recover
    > from a programming error? If the program is broken fix it. Writing
    > logic to recover from a bug elsewhere in the program seems
    > counter-productive. If the argument is illegal, change the code so
    > that it provides a valid argument. Writing an exception handler that
    > somehow forces the program to continue will only lead to fragile software.


    You don't have to write an exception handler. You can also propagate the
    exception.
    Anyway, in any case when you have necessity to rollback (a database, a
    file, maybe just writing data to a class), you need to catch whatever
    exception, even if it's coming from a programming error.
    I know, in that case I can simply catch a Throwable and do my error
    handling, but my point was just that a programming error is not always
    something you have to let go

    >
    > These "programming errors" are where the programmer failed to express
    > their intentions correctly in source code. Part of the program does
    > not work as it was intended to. If the intention of the program is not
    > clear it is unreasonable to expect the program to work correctly.


    as well as in many other cases when the error is not a programming error


    >
    > Can you imagine how frustrating it would be if exceptions like
    > IllegalArgumentException, ArrayIndexOutOfBoundsException and
    > ArithmeticExcepion were checked exceptions? Every array access would
    > have to be within a try...catch block, just in case you stuffed up with
    > the indexing. Every division would have to explicitly deal with the
    > possibility of division by zero (even if you can be certain that the
    > divisor is non-zero). And if your IllegalArgumentException was
    > checked, your method/constructor could be documented as follows:
    >
    > 1). Please provide valid arguments.
    > 2). Please provide code to deal with your inability to follow the
    > first instruction.


    true. And this is the reason why RuntimeException is not checked.
    At the end, as it usually is and as it has been pointed out already, it
    depends on the context. Maybe I will look at it (I promise I will :))
    and I will decide to use RuntimeException more often, but I just like
    the idea that my exceptions are checked. What can I say? I'm always
    concerned I can forget something.
     
    Andrea Desole, Jul 12, 2005
    #9
  10. -

    Daniel Dyer Guest

    Re: When is a good time to create a custom Exception class rather than using IllegalArgumentException most of the time?

    On Tue, 12 Jul 2005 18:40:36 +0100, Andrea Desole
    <> wrote:
    > Daniel Dyer wrote:
    >> Can you provide an example where it would make sense to
    >> handle/recover from a programming error? If the program is broken fix
    >> it. Writing logic to recover from a bug elsewhere in the program
    >> seems counter-productive. If the argument is illegal, change the code
    >> so that it provides a valid argument. Writing an exception handler
    >> that somehow forces the program to continue will only lead to fragile
    >> software.

    >
    > You don't have to write an exception handler. You can also propagate the
    > exception.
    > Anyway, in any case when you have necessity to rollback (a database, a
    > file, maybe just writing data to a class), you need to catch whatever
    > exception, even if it's coming from a programming error.
    > I know, in that case I can simply catch a Throwable and do my error
    > handling, but my point was just that a programming error is not always
    > something you have to let go


    Maybe we are using different definitions of "programming error". I/O can
    go wrong even if the program is written perfectly. You can't, for
    example, guarantee that some other process won't fill up the disk while
    you are writing to a file or that there won't be a network problem. In
    these cases I agree that a checked exception is best because it forces the
    programmer to consider these situations. But for the narrower definition
    of "programming error" that I was thinking of, where things are guaranteed
    to work if you write the code properly, such as accessing an array or
    calling a method with the right arguments, I think it's overkill.

    Getting back to the original poster's question about the use of
    IllegalArgumentException, I would say that it should be used to validate
    that arguments are acceptable according to the specification of the method
    (which should be documented). Therefore you should know for certain
    before you call the method (or constructor) with a given set of arguments
    whether an exception will result. If you know this for certain in advance
    you can avoid it. If you can write the code in such a way that this
    exception is guaranteed never to occur it makes no sense to make the
    exception checked or even to catch it.

    As Chris pointed out, there is no good reason to write another exception
    type for this purpose. If you have arguments that are illegal, then use
    java.lang.IllegalArgumentException. There's no need for a
    com.mydomain.InvalidParameterUsageException or an
    org.apache.commons.ThisMethodCallIsntQuiteRightException.

    If however you are doing something more than just simple validation with
    your arguments then IllegalArgumentException might not be right. Suppose
    you are parsing a String that is passed in as an argument. The argument
    might be considered illegal because it's in the wrong format, but maybe a
    ParseException or something else is a better choice. Mostly it's a
    judgement call depending on the specifics of the situation.

    Dan.



    --
    Daniel Dyer
    http://www.dandyer.co.uk
     
    Daniel Dyer, Jul 12, 2005
    #10
  11. -

    Chris Smith Guest

    Re: When is a good time to create a custom Exception class rather than using IllegalArgumentException most of the time?

    Daniel Dyer <> wrote:
    > Getting back to the original poster's question about the use of
    > IllegalArgumentException, I would say that it should be used to validate
    > that arguments are acceptable according to the specification of the method
    > (which should be documented). Therefore you should know for certain
    > before you call the method (or constructor) with a given set of arguments
    > whether an exception will result. If you know this for certain in advance
    > you can avoid it. If you can write the code in such a way that this
    > exception is guaranteed never to occur it makes no sense to make the
    > exception checked or even to catch it.


    Agreed. In some cases, the focus on avoidability is very enlightening.
    I'd be more precise and say the question is who "should" realize that
    the argument is wrong. In many cases, libraries are computationally
    deterministic and it's possible to avoid passing bad arguments, but the
    question is still decided by where the detection of bad arguments ought
    to occur. If the calling code "should" have known about the problem
    before calling the method, then it is a programmer error. If the code
    being called is the first location that "should" recognize a problem
    with the arguments.

    For example, it may be a requirement that some argument needs to be
    relatively prime to some intermediate result from a complex math
    calculation. If the complex math calculation is pertinent to the
    library's problem space, then the logic for checking the input most
    likely logically belongs to the library. IllegalArgumentException is
    not appropriate in that case. The same is true for most parsing code.

    Invariably, when explaining this, someone asks about the standard API,
    NumberFormatException, and Integer.parseInt. This is a border case, but
    the reasoning is basically this: NumberFormatException should only be
    used for data that's produced programmatically, stored as text, and then
    read back. If nothing goes wrong, there is no possibility of getting a
    badly formatted number. User input (which often uses parseInt in
    practice, IME) ought to be using the java.text.NumberFormat class --
    which, lo and behold, throws a checked exception onm failure. The
    border-ness comes from the fact that some "advanced" users are
    inevitably going to view and try to edit an application's internal data
    files when they are stored as text. These users, when they screw
    something up, might arguably deserve better than an application crash
    for it.

    > As Chris pointed out, there is no good reason to write another exception
    > type for this purpose.


    Hmm. I actually said there's no good reason to throw a checked
    exception. Although you're obviously not thinking of this, there could
    be a very good reason to throw a subclass of IllegalArgumentException,
    which means writing a new exception type. Off-hand, this could be done
    because it might be useful to include more information or context about
    why the argument was illegal.

    In any case, some time ago I wrote a short presentation for the Pikes
    Peak Java Developers Group on exception handling practices. You can
    find it at:

    > http://www.ppjdg.org/presentations/java_essentials/Exception Handling Practices.ppt


    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Jul 12, 2005
    #11
  12. -

    Daniel Dyer Guest

    Re: When is a good time to create a custom Exception class rather than using IllegalArgumentException most of the time?

    On Tue, 12 Jul 2005 22:55:29 +0100, Chris Smith <> wrote:

    > Daniel Dyer <> wrote:
    >> As Chris pointed out, there is no good reason to write another exception
    >> type for this purpose.

    >
    > Hmm. I actually said there's no good reason to throw a checked
    > exception.


    OK, sorry. I read your first two paragraphs as if they were two separate
    points.

    Dan.

    --
    Daniel Dyer
    http://www.dandyer.co.uk
     
    Daniel Dyer, Jul 13, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Klein

    VHDL-AMS MOS Level3

    Stefan Klein, Aug 12, 2005, in forum: VHDL
    Replies:
    0
    Views:
    653
    Stefan Klein
    Aug 12, 2005
  2. Neomorph

    Re: IllegalArgumentException

    Neomorph, Aug 14, 2003, in forum: Java
    Replies:
    2
    Views:
    444
    Neomorph
    Aug 15, 2003
  3. Replies:
    0
    Views:
    2,411
  4. Python Nutter

    Python on iPhone actually rather good

    Python Nutter, Nov 4, 2008, in forum: Python
    Replies:
    0
    Views:
    438
    Python Nutter
    Nov 4, 2008
  5. pete
    Replies:
    3
    Views:
    501
    Seebs
    Dec 17, 2010
Loading...

Share This Page