Yet another stupid function



  • It's not even used anywhere. Which probably is for the best. 

     

             private double convertStringToDouble(string val)
            {
                CommonParser cParser = new CommonParser();
                try
                {
                    return double.Parse(val, CommonParser.ni);
                }
                catch (Exception ex)
                {
                    throw ex;
                }
            }

     



  • Ooh, is this another one of those "count the WTFs" posts?

    I only count two:

    1. Instantiating a CommonParser object but not actually using it, just using a static property from the class instead (unless said static property is being initialized in the object's constructor, which would be even more of a WTF).
    2. Catching all exceptions, only to throw them immediately afterwards. Who needs a full stack trace, anyways?
    The fact that this is actually a function is probably because they wanted to avoid having to specify the number format during every conversion (since C#'s double.Parse() would appear to default to your current locale rather than a culture-invariant format).


  • @Quietust said:

    1. Catching all exceptions, only to throw them immediately afterwards. Who needs a full stack trace, anyways?

    Note that its being thrown as Exception. Which seems to be the standard with some "common library" classes some genius did over here. Imagine finding something like:

    public void setDataSource(String dataSource) throws Exception {

    ...

    }

    on a method. As the name states, I pass a JNDI location for the datasource, and it extracts an SQL Connection. It does it just fine, but the programmer was lazy and decided to just "throw Exception" and forget about what kind of Exception he's really throwing.



  • @Quietust said:

    Ooh, is this another one of those "count the WTFs" posts?

    1. Catching all exceptions, only to throw them immediately afterwards. Who needs a full stack trace, anyways?

     

     

    I can't speak for C#, but this behavior doesn't eliminate any part of the stack trace in Java. Consider the output of:

     public class Temp {

        public void t () throws Exception  {
            throw new Exception("test");
        }
       
        public static void main(String[] args) throws Exception{
                    try {
                        Temp t = new Temp();
                        t.t();
                    }catch(Exception e) {
                        throw e;
                    }
                   
        }
    }



  • @Nether said:

    I can't speak for C#, but this behavior doesn't eliminate any part of the stack trace in Java.

    Actually, it does in C#. It seems to be a common mistake to write throw ex; in C# which means you see a lot of stack traces that just shows you the line of the throw ex; statement. You should just write throw; which rethrows the original exception (I think).

     



  • @Gieron said:

    @Nether said:

    You should just write throw; which rethrows the original exception (I think).

    It does that.

    Does writing the Exception type in the declaration of methods in Java cause the errors thrown to be cast to that type, or do they still keep their types if they inherit from the declared one?



  • [quote user="Renan "C#" Sousa"]

    Does writing the Exception type in the declaration of methods in Java cause the errors thrown to be cast to that type, or do they still keep their types if they inherit from the declared one?[/quote]It will be "seen" by the calling method as being of type Exception; so yes it is basically cast as Exception. You could re-cast it into the actual sub-class if you know which Exception to expect, but that doesn't save you from having to enclose said call inside a try/catch block that catches the general Exception.


  • What? Two exceptions for the entire program? WTF?



  • @Quietust said:

    I only count two:

    1. Instantiating a CommonParser object but not actually using it, just using a static property from the class instead (unless said static property is being initialized in the object's constructor, which would be even more of a WTF).

    He could also be setting it with a static constructor (or even just a initlaizer), and may erroneously believe he must create an object before those initializers happen, when in fact both static initializers and the static constructor are guaranteed to run (in that order) prior to any static member access or constructor call. Still a WTF for not knowing when static fields are initialized, but not as bad as initializing in the instance constructor.

    @Quietust said:

    1. Catching all exceptions, only to throw them immediately afterwards. Who needs a full stack trace, anyways?

    Interestingly enough: the MSDN documentation (as of Visual Studio 2008) on try/catch blocks states that when you have a parameter, you use 'throw ex;' to rethrow and never mentions that doing so trashes the stack trace.


Log in to reply