question about misterious exception behavior

[juliane gross]

I throw an exception in my class method, and it works fine (hope, Marilyn thinks that too, this time ).
Just because I am at exception throwing anyway I thought of adding an: throws ArrayIndexOutOfBoundsException to my main method, to handle if the user does no input or in the wrong number of arguments.
I handled the code exactly analog to the working exception throwing method.
But instead of nicely throwing this thing in the main method as well, my compiler tells me: cannot resolve symbol.
Can somebody resolve the mistery, please?
thank you,
Juliane
[ December 11, 2002: Message edited by: juliane gross ]

[Barry Gaunt]

Hi Juliane,
you do not need a throws for Array-dadida-Exception because it is an unchecked exception. If you do throw the exception then you
should catch it yourself because your customer don't want to see any stinking exceptions.
Could it be that you have something like this?:

try
{
    int[] littleArray = new int[ 42 ] ;
    int nummer = Integer.MAX_VALUE ;
    int x = littleArray[ nummer ] ;
}
catch ( Array-dadida-Exception e )
{
    System.out.println( nummer );
}

That will not compile (Why?). Maybe you have to
be a little more speshific...
-Barry (Hic)
Or do you mean something like:

public static void main( String args ) throws A27n
{
    throw new A27n();  // you are using "new" ?
                       // got () ?  
}

[ December 11, 2002: Message edited by: Barry Gaunt ]

[juliane gross]

Thanks for answering, Barry.
your second code example is the case:
main method blabla throws Exceptionthing
and I put a Message String between the ()
to show up for misbehaving users.
Please give me a hint regarding: no need to throw unchecked exceptions.. what exactly is meant by that?

Juliane

[Barry Gaunt]

There are two kinds of Exceptions: checked and
unchecked. Unchecked Exceptions are those derived
from RuntimeException and you do not have to
declare them in a throws clause (in a method header).
ArrayIndexOutOfBoundsException is derived from IndexOutOfBoundsException which is derived from RuntimeException so it is unchecked. An java.io.IOException is a checked exception and must be caught (try/catch) or declared to be thrown in the method header ( like void aMethod() throws java.io.IOException).
You can throw any kind of exception, checked or unchecked. For example

throw new ArrayIndexOutOfBoundsException( "message" );

is valid.
Are you sure you have the new there?
Is the "message" a String literal or a String reference? If a reference, is it valid in the catch block? Or outside the main method? In fact what is outside the main method?
Do you really mean the

public static void main(String[] args) 

main method?
Try to write the simplest code snippet that demonstrates your problem without giving us
the real assignment code and post it here.
Good luck
-Barry
[ December 11, 2002: Message edited by: Barry Gaunt ]

[Barry Gaunt]

Juliane, is this code something like it?

public class X
{
    public static void main(String[] args)
    {
        X x = new X();
        try
        {
            x.google();
        }
        catch (Exception e)
        {
            String p = e.getMessage();
            System.out.println(p);
        }
    }
    
    void google()
    {
        String p = "bad things";
        throw new ArrayIndexOutOfBoundsException( p );
    }
}

[juliane gross]

Hi Barry,
thanx a lot for taking your time! Checked/unchecked exceptions are now clear to me. I just found my rather stupid mistake:
I did:

public static main( String[] args ) throws LongNameException
{
    if( ...)
    {
        do stuff
    }
    else
    {
        LongNameException = new LongNameException( "message" );
        throw LongNameException ;
    }
}

see, my LongNameException was so long I lost sight of what was there. I brooded a very long time over it without seeing the obvious
Sometimes it helps to go outside and subject the brain to some fresh air ..
Anyway, your various code snippets helped me to reorganize my general knowledge about exceptions and fill some gaps doing this.
Hoping, those mistakes stay Exceptions!
Juliane
[ December 13, 2002: Message edited by: juliane gross ]

[Pauline McNamara]

Hi Julianne,
If I understand correctly what you want to throw an exception for
"...to handle if the user does no input or in the wrong number of arguments."
maybe it would be simpler to deal with it using an if block in main that checks the args array and then writes a message back to the user (like in the instructor's solutions in earlier assignments)?
Just a thought, for whatever it's worth...

[juliane gross]

Pauline, if/then constructions is exactly what I am usually doing - I was just curiously experimenting with exception throwing and wanted to see if it would work as well with the main method;
what do you think: is there a reason why I should prefer one way over the other? Or maybe is it just a question of convention?
That would be interesting to know.
Juliane

[Pauline McNamara]

Originally posted by juliane gross:
Pauline, if/then constructions is exactly what I am usually doing - I was just curiously experimenting with exception throwing and wanted to see if it would work as well with the main method;

Aaaha, experimenting

what do you think: is there a reason why I should prefer one way over the other?

In the most general terms, what you do usually depends on what your ultimate goals are. In the context of the Cattle Drive, it's usually best to keep things simple. Since previous assignments dealt with user input using simple conditional statements within main, I figured that would be a safe way to go.

Or maybe is it just a question of convention?
That would be interesting to know.
Juliane

Yes, this would be interesting to know.
As I understand exceptions, I think you'd use them to deal with unpredicatable errors in your program, to make sure to stop it and get out of the situation safely. It's kind of predicatable, though, that users will forget some input, or enter it incorrectly. Rather than stop everything by throwing an exception, it seems to make sense to me that you would just foresee the situation and then give the user some feedback so you can start over again, all as part of the natural flow of the program.
Now if we could just get the perspectives from some of the stars out there... Barry, where'd you go?

[Marilyn de Queiroz]

If you can do something without any exception stuff, that is generally preferred. I would usually prefer the if/else over throwing the exception because throwing exceptions is a glorified "goto" and "goto" is to be avoided if possible.

However, there are times when throwing an exception may be acceptable. Sometimes there is no easy way to test using an if/else.

[Barry Gaunt]

Now you know why I delayed answering this one!
I've been dunked in the horse trough enough times recently.
-Barry

[paul wheaton]

I'm trying to clear out a back-log of unread e-mails and came up with one from Marilyn asking me to look in on this thread (now rather old and moldy). Sorry for the delay.
First, for almost all of my standalone utilities, I figure it's just me using it or it might be another geek like me - I'll often declare main as "throws exception". Then only catch exceptions once in a while.
BUT! In the case of checking the number of arguments, all of my programs first check that the number of args is appropriate: if ( args.length == 1 ) { ... do my thing ... } else { ... report proper usage ... }
In the first message there was mention of checking a parameter that was sent in. So I was thinking that we were talking about some other method. And in that case, if the user (another programmer using the method - or possibly even me) passed in an array that's too short I might generate an exception like InvalidParameterException. But usually I only do this if it's method that returns void or a constructor (which, of course, returns nothing). Cuz the code I write starts off with something like:

// returns null if you passed in crapulent data
private String fooBar( String[] fodder )
{
    String returnVal = null ;
    if ( fodder.length > 4 )
    {
        // work it baby!
    }
    return returnVal ;
}

Hope this helps!

[juliane gross]

Yes, sure! Thank you !