• BillyBob (unregistered)

    I suspect this person was using an IDE which suggested wrapping the line which throws an exception in a try catch block to get around the compilation error. If it's the one I'm thinking about, it would have added the code for him/her as well if s/he wanted.

    This is what happens when you let a machine do the thinking for you.

  • Talchas (unregistered) in reply to brazzy
    brazzy:
    If you can't do anything useful with an exception, at least log it. The only valid reason for silently swallowing exceptions is in unit tests where the exception can be the expected result and you only want the test to fail when it doesn't occur. If an API forces you to swallow useless exceptions as part of the normal flow of operations, then that API is crap.
    Second reason (although almost always a bad reason) - you are using exceptions as flow control. Although in that case you probably shouldn't be using an Exception, but some other Throwable.
  • (cs) in reply to brazzy
    brazzy:
    If you can't do anything useful with an exception, at least log it. The only valid reason for silently swallowing exceptions is in unit tests where the exception can be the expected result and you only want the test to fail when it doesn't occur. If an API forces you to swallow useless exceptions as part of the normal flow of operations, then that API is crap.

    If you have any complex conversation on Java through sockets, the only reliable way of interrupting a thread that is expecting a message is closing the socket.

    This throws exceptions, and even if the docummented way of thread.interrupt worked, it would also throw an exception. Often, there is nothing you want to do with this exception... And, yes, this API is crap.

  • (cs)

    A better way to write this would be

    try {
  throw new Exception("Error");
}
catch (Exception ex) {
  try {
    throw new Exception("inserting");
  }
  catch (Exception ex) { 
    try {
      throw new Exception("description");
    }
    catch (Exception ex) {
      try {
        throw new Exception("!");
      }
      catch (Exception ex)
      {
      }
    }
  }
}
  • Jens Fudge (unregistered)

    Aaahh... Memories bring me back....

    Reminds me of my first job as a programmer (in 1996) where a coleague writing Visual Basic had some stupid error popping up once in a while in a large project.... One day he was absolutely gleaming with joy as he solved the problem:

    On error resume next

    It was a glorious day for him!!!

  • Heinz Gorgon Mittelmacher (unregistered) in reply to gruckiii
    gruckiii:
    I know in other languages it is permissible to catch the general Exception class.. but in Java I thought you were not supposed to (except in a few cases). Catching the general exception class in java also catches the out of memory and runtime exceptions which you can not do anything about.

    No, Out of memory and other hard exceptions are subclasses of Error in Java, not Exception. So they wouldn't be caught. Things may be different in C#, at least I've found one logfile chock-full of reports about OutOfMemoryExceptions.

  • Jimmy Jones (unregistered)

    Ummmm...guys, I think the idea is to see a message on the "exceptions" console, then continue....

  • sprx (unregistered) in reply to Dan
    Dan:
    The code presented won't even compile since the method does not declare that it throws Exception.

    If it's the case that the code actually catches Exception and throws RuntimeException (which would not have to be declared in the method signature), it might be slightly more forgiveable.

    The method doesn't have to throw an Exception, cause its already caught within the method and never leaves it.

  • sprx (unregistered) in reply to Malfist
    Malfist:
    This is really sad, not only does it throw and catch it's own exception and then do nothing, it also casts the exteption upwards so you lose the data of what it was to begin with.

    Well I believe that is not true. The caught Exception is still of the type that is actually thrown. So you will at least be able to read out its message. And with .getClass(). you can even retrieve its actual type. Though that is not the way to do it. And catching a highest level Exception is still a WTF in most cases.

  • nahguam (unregistered)

    Would this work? :p

    public void RecurseException(Exception error)
{
    try
    {
        //do stuff
    }
    catch (Exception e)
    {
        RecurseException(e);
    }
}
  • nahguam (unregistered) in reply to nahguam

    I meant this:

    public void RecurseException(Exception error)
{
    try
    {
       throw new Exception("ouch");
    }
    catch (Exception e)
    {
        RecurseException(e);
    }
}
  • sprx (unregistered) in reply to nahguam
    nahguam:
    I meant this: 
    public void RecurseException(Exception error)
{
    try
    {
       throw new Exception("ouch");
    }
    catch (Exception e)
    {
        RecurseException(e);
    }
}

    dispite that it will end in an infinite loop, I can see no syntax errors. :)

  • (cs) in reply to 604
    604:
    Good lord, please tell me that is the work of more than one brain dead developer. I can wrap my mind around the concept of one person writing throwing the new exception... and then someone else coming along and "fixing" it, but if this was written by a single coder I sure hope he was sniffing glue at the time.
    just taking a shot at what happened: Coder A wrote initial method with a catch block like this:

    catch { throw new Exception ("blah"); }

    then the PHB got a complaint about error "blah" popping up all the time and sends coder B in to squelch it. Instead of simply commenting out the throw statement, they decided to wrap it in a try..catch block and swallow the new exception.

  • (cs) in reply to brazzy
    brazzy:
    What I meant with crap API is one where in the normal course of events you are forced to catch exceptions that actually DO occur and do nothing with them - where the exception is the expected result but doesn't convey any information about actual exceptional circumstances.

    Ah, I see. In that case, yes that would be pretty crap API :) .

  • (cs)

    I can (almost) see a possible use for this (albeit an ugly one) -- if the Exception being created was instead a custom one which wrote to a log file. I've seen it before, and it's a cheap way of logging any custom exception.

    import java.util.Date;

    public class Log
{
public static void println(String msg)
{
System.err.println(new Date() + ": " + msg);
}
    

    public static class LogException extends RuntimeException
{
public LogException(String msg)
{
super(msg);
println(msg);
}
}
}
    

    public class SomethingWentWrongException extends Log.LogException
{
public SomethingWentWrongException()
{
super("something isn't quite so brillant");
}
}
    

    public class Test
{
public static void main(String args[])
{
try
{
throw new SomethingWentWrongException();
}
catch (Exception e)
{}
}
}

  • CodeCheetah (unregistered)

    i guess the developer did not want to outsource the exception handling.

  • [twisti] (unregistered)

    Something I recently found among my old source (comment left intact for your amusement):

    try { url = new URL("http://www.obfuscated.com/server.php"); } catch (MalformedURLException e) { // THIS CAN NEVER EVER HAPPEN! System.out.println("DANGER! REALITY DAMAGED!"); System.exit(1); }

    One of the few cases where it makes sense for the API to throw an exception, and makes no practical sense for me to catch it (since the URL is hardcoded and will not ever change).

    Captcha: ewww, very fitting.

  • Morris (unregistered) in reply to Raymond Chen

    Looks like debug code to me...

    1. Presume the IDE/debugger normally breaks execution at the point an exception is raised.

    2. Some types of exception are configured to be ignored from the IDE (so they do not break execution). This is usually done for exceptions that occur regularly within code as part of normal runtime behaviour.

    3. The code happens to throw one of the 'ignored' exceptions, but the programmer wanted to have the debugger break even thought that 'ignored' exception occurred. (e.g. the 'ignored' exception occurs a million times elsewhere (poor programming style?) during execution so they want to ignore it!)

    4. The programmer wants to squelch the exception in a production environment.

    I admit it - I recognise the idiom because I have used it in another language (although at least I commented the reason).

  • Todd (unregistered)

    Actually, when I read this, it made me throw up in my mouth a little.

    -Todd Put down the sig. and step away from the computer.

  • darwin (unregistered) in reply to Morris
    Morris:
    I admit it - I recognise the idiom because I have used it in another language (although at least I commented the reason).

    If this is debug code, it needs to be commented (as you said you did). But I'm surprised no one commented on the other comment here, the totally useless javadoc comment auto-generated by the IDE.

    The app I'm working on is full of these, and none of the other programmers seem to care or think it's worthwhile to write javadoc. Or, if they do, they add their comment below the junk spewed out by the IDE, so you will see something like:

    /**
 * Insert the method's description here.
 * Creation date: (2/15/02 11:07:49 AM)
 *Method to get the first container id.
 */

    Or:

    /**
 * @author jfoo
 *
 * To change this generated comment edit the template variable "typecomment":
 * Window>Preferences>Java>Templates.
 * To enable and disable the creation of type comments go to
 * Window>Preferences>Java>Code Generation.
 */

    It drives me nuts!

  • Zonkers (unregistered) in reply to lmollea
    <html> I remember a code from a terrible project I had to work with. JSP pages that never failed. Never.

    All JSP were something like:

    <% try { %> .... ... jsp .... <% } catch(Exception e) { } %>

    </html>

    Oh my lord! I practically had a heart attack seeing that. Now that would make a great WTF.

Leave a comment on “If At First You Don't Succeed”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article