aspose file tools*
The moose likes Beginning Java and the fly likes Error message....dont know what it means Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Error message....dont know what it means" Watch "Error message....dont know what it means" New topic
Author

Error message....dont know what it means

Sally Curtis
Greenhorn

Joined: Jan 10, 2004
Posts: 26
does anyone one know what the following error message means?

'case', 'default' or '}' expected

i have like 50 of them in my program when i compile
Billybob Marshall
Ranch Hand

Joined: Jan 27, 2004
Posts: 202
You probably have malformed 'switch' statement(s). They need to look like this:
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
i have like 50 of them in my program when i compile

When you're trying to understand and resolve compile-time error messages, I'd recommend just focusing on and trying to fix the the first one. When you think you've got that problem figured out, compile and see what the compiler thinks.
Also, take baby steps when writing programs. You shouldn't have 50 lines of code with a dozen syntax errors. It can be gruesomely messy trying to figure out resolving a dozen problems at the same time in a program. Write a couple of lines, then compile and fix any problems before progressing. That way you've often never more than one or two small problems to interpret, understand, and correct.


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
sever oon
Ranch Hand

Joined: Feb 08, 2004
Posts: 268
In response to BillyBob's response, I've never seen a switch statement that looks like the one he posted. I would recommend against creating a new scope for each case, as he did by putting {}'s around the code for each case. Instead, I'd do the standard thing:

The reason I disagree with BillyBob is that you always want to write code that is maintainable--consideration for other programmers (and yourself) later on, should the code need to be modified. So, along that vein:
  • Always either put a break after each case, or an explicit comment stating that you intend to fall-through to the next case.
  • Always provide a logical ordering of your case statements where possible. This is not necessarily numerical order...for example, you might have numerical constants defined called RARE, MEDIUM_RARE, MEDIUM, MEDIUM_WELL, and WELL, and they should be presented in that order even if the actual numerical values assigned to those constants are, respectively: 100, 50, 75, 200, and 52.
  • Always include a default case, even if it does nothing. Most of the time you will not want to do nothing, especially if every possible case has already been accounted for. If every valid case is already handled with a "case XXX:", then default should not do nothing, it should throw an exception indicating that, if the default ever executes something went wrong. If you do indeed want the default case to do nothing, put an explicit comment there saying: "do nothing".
  • Always put your default case last--that's convention and other programmers will expect to see it there. You will too, once you start reading other people's code, so be considerate to others (and your future self) and reciprocate.
  • Always terminate the final case statement, which should be the default, with a break, even if it's empty and only has a comment saying "do nothing". Why? What if someone comes along and carelessly adds another case at the bottom, instead of putting it in its proper place? Do you want your previously-last case statement to fall-through to the now-last case statement? I think not, so program defensively. The decision to fall-through should be left to the new programmer, and that person should have to explicitly alter your code to get it to fall-through if that's what's intended.


  • I am objecting to BillyBob's use of scoping with {}'s because they are not a conventional part of a switch statement, and with good reason. The switch statement is explicitly designed to allow fall-through from one case to another. When using fall-through, it's often necessary to use a variable that was defined in the previous case--alas, now that variable no longer exists because it's gone out of scope.
    Let's say that you are writing a switch in which there are no fall-throughs. Then is it ok to set each case statement in its own scope? No, I say. Down the road, it may be necessary to change that code, and often with switch statements that change amounts to making one or more of those cases fall-through to the next one. To do this, the code should be written so that the relevant breaks can simply be replaced with "fall through" comments.
    Less frequently, but equally valid, is the situation where you DO want to break after each case, but you still want to have access to variables in other cases. Again, you might not require this capability, but down the road the code might have to be changed, so don't make the next guy go through all your switch statements and remove all those internal braces.
    On the other hand, sometimes you want to explicitly scope a certain variable or set of variables in order to invite the JVM to garbage collect those items. I once wrote a program that read a large file into memory at the beginning of a loop, computed a checksum on that file, and then the block inside the loop continued for several hundred lines (and several seconds of execution time). There was no reason to keep that large file around in memory once the checksum was computed even though the variable was still in scope. So I put {}'s around where I declared that variable and it went out of scope earlier than it otherwise would have. (Actually, you might wonder, why not just set it to null--this is correct, but I simplified my example. I actually had LOTS of variables each pointing to a lot of data, and setting them all to null one after the other was tedious and prone to missing one. So, putting them all in a scope was a more elegant solution.)
    (Incidentally--since the compiler probably optimizes this out anyway and makes those variables available for garbage collection, seeing that they'd not be used again in the scope of the loop, but just to be sure I put in the extra scope anyway.)
    sev
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Error message....dont know what it means