Re: Help! Where's my UIManager

On Apr 29, 11:39 am, Jean-Baptiste Nizet <jni...@xxxxxxxxx> wrote:
On 29 avr, 16:58, Zerex71 <Zere...@xxxxxxx> wrote:



Yes, the compiler is catching the four listed exceptions, which I find
weird - I thought exceptions were only runtime artifacts. I saw this
try-catch block as an example and didn't implement it. I thought,
"Why can't I just make the calls and let the chips fall where they
may?" But since it won't compile, I'm under the impression that it
simply can't find the UIManager. What's worse, if I try to type the
import statement (I use Eclipse), with each "filtering", I get to the
end of the line and there's no UIManager class anywhere, further
bolstering my opinion that somehow the class isn't even present.

Mike

Sorry if this sounds rude, but you should probably read a book about
basic Java programming if you don't understand how imports and
exceptions work.

The UIManager class IS present, and you should be able to import it.
BTW, if the compiler signals errors about your code not catching these
exceptions, this means that it has found the class. When the compiler
signals an error, you MUST fix it: the code won't even be compiled and
you won't be able to run it.

Regarding exceptions, Java has two kinds of exceptions: "normal"
exceptions, and runtime exceptions. Runtime exceptions all derive from
the class java.lang.RuntimeException. A runtime exception may be
ignored by the caller of a method that might throw it. But a normal
exception MUST be taken care of by the caller method: either it lets
it go to the parent caller (by declaring "throws FooBarException"), or
it catches it. If the caller method doesn't declare the exception and
doesn't catch it, the compiler will refuse to compile your code.

The example I gave you catches all the declared exceptions, and throws
a runtime exception if it happens (which should never be the case).

JB.

I used your code suggestion and the LAF is still the same Windows-
looking thing. I want the Java variety. It's not working for me.
.

Relevant Pages

  • Re: Benefits of Dynamic Typing
    ... >> - On the toplevel of the compiler, to report all compile errors found ... > Catching and reporting all exceptions in the toplevel doesn't require ... Note that I don't use exceptions much. ... exception for reporting an end of file though. ...
    (comp.lang.functional)
  • Re: Handling error/status messages by interface to C++ programs
    ... about how to design a compiler, please tell me where I can find ... exceptions for managing the error detection is rather a bad idea. ... I have to say I have seen a simple example of an object-oriented parser design in some book (unfortunately I forgot ... It would trigger user notification and do recover housekeeping like reseting the current syntax row's token stack because one wants to continue parsing and detect any other errors w/o aborting. ...
    (comp.object)
  • Re: Cpp Considered Harmful
    ... programming language, the compiler, the IDE, the libraries, etc. ... WRT exceptions, the fact of the matter is that placing certain ... >> regarding the CPP. ...
    (comp.lang.cpp)
  • Re: Fortran Error Reporting Requirements (Was: GFORTRAN PROBLEM WITH SAVE STATEMENT)
    ... If you ever had a compiler that failed to diagnose this, ... to trap exceptions. ... Reporting of violations of syntax rules and constraints is required in section 1.7.3. ... Most of the detection and reporting requirements are in section 1.5, ...
    (comp.lang.fortran)
  • Re: Benefits of Dynamic Typing
    ... an extendible type hierarchy. ... which means "the compiler found a fatal error and it cannot continue compiling this module, so we return to compiler's toplevel code and print errors found so far before exiting". ... in a type hierarchy, so that doesn't decide the point in question. ... Actually I think it promotes nonlocal dependencies, because exceptions tend to expose local information to an entirely different abstraction layer. ...
    (comp.lang.functional)