How to catch everything?

A

aaronfude

Hi,

I have this code:

public static Universe gLoadUniverse(String uvName) {
try {
System.out.println("I'm here");
ObjectInputStream ois = new ObjectInputStream(new
FileInputStream("C:/a.obj"));
System.out.println("I'm here");
Universe uv = (Universe) ois.readObject();
System.out.println("I'm here " + uv);
return uv;
}
catch (Exception e) {
System.out.println("I'm here " + e.getMessage());
e.printStackTrace();
return null;
}
}

It prints out the first to I'm here's, but nothing else.and quits. So
in "Universe uv = (Universe) ois.readObject();" something goes wrong,
but I don't get any feedback whatsoever. Is there something else that
I may not be catching?

Thanks!

Aaron
 
S

Sideswipe

Actually, "Universe uv = (Universe) ois.readObject();" is after the
2nd "I'm here" -- so, if you're only seeing 1, then chances are your
error is in your attempt to load your ObjectInputStream. If you are
getting NO stack trace or output at all, then (since, you are
referencing a file on Windows) your ObjectInputStream constructor is
blocked.

However, I have never known that method to block. You could try going
to the top of the catch chain and catch(Throwable t). Let me know how
you make out and... make sure to rate this post

Christian
http://christian.bongiorno.org

Try this, try writing an object out, then closing the file and
immediately reading it back in
 
A

aaronfude

Actually, "Universe uv = (Universe) ois.readObject();" is after the
2nd "I'm here" -- so, if you're only seeing 1, then chances are your
error is in your attempt to load your ObjectInputStream. If you are
getting NO stack trace or output at all, then (since, you are
referencing a file on Windows) your ObjectInputStream constructor is
blocked.

However, I have never known that method to block. You could try going
to the top of the catch chain and catch(Throwable t). Let me know how
you make out and... make sure to rate this post

Christianhttp://christian.bongiorno.org

Try this, try writing an object out, then closing the file and
immediately reading it back in






- Show quoted text -

Sorry, I meant to write the "the first two I'm here's".
 
L

Lew

Sideswipe said:
make sure to rate this post

Please stop asking folks to "rate" your posts. In the first place, not
everyone uses your little kiddie reader. But since you asked -

I rate your post jejune and in violation of netiquette. You top-posted
instead of inlining your response. You asked for a rating instead of focusing
Actually, "Universe uv = (Universe) ois.readObject();" is after the
2nd "I'm here" -- so, if you're only seeing 1,

but the OP said:
It prints out the first to [sic] I'm here's,

They saw two "I'm here" outputs, not one.

So your post rates: POOR.
 
P

Patricia Shanahan

Hi,

I have this code:

public static Universe gLoadUniverse(String uvName) {
try {
System.out.println("I'm here");
ObjectInputStream ois = new ObjectInputStream(new
FileInputStream("C:/a.obj"));
System.out.println("I'm here");
Universe uv = (Universe) ois.readObject();
System.out.println("I'm here " + uv);
return uv;
}
catch (Exception e) {
System.out.println("I'm here " + e.getMessage());
e.printStackTrace();
return null;
}
}

It prints out the first to I'm here's, but nothing else.and quits. So
in "Universe uv = (Universe) ois.readObject();" something goes wrong,
but I don't get any feedback whatsoever. Is there something else that
I may not be catching?

Thanks!

Aaron

You could try changing "Exception" to "Throwable" to include Error and
its subclasses as well as Exception. However, depending on what else is
going on in the calling code, I would have expected an Error to cause
some visible symptoms.

As a wild eyed guess, could there be a recursive call loop in the
readObject() code?

Patricia
 
T

Twisted

As a wild eyed guess, could there be a recursive call loop in the
readObject() code?

I read the OP's post as indicating it is exiting without an error
message, rather than hanging. Infinite loops tend to mean hanging, or
an eventual Error due to memory use or stack overflow.

A symptomless exit shouldn't result from readObject() unless one of
four things is true:
a) a non-Exception Throwable is thrown (likely an Error), caught
(further up the call chain), and the handler exits silently without
dumping a stack trace. This eliminates the default
uncaught-exception handlers that come with the JRE.
b) Something under readObject() calls System.exit(0) or similarly.
This could be in a user class readResolve() method or similar
location.
c) The exit is caused outside of Java, e.g. through JNI or a
Runtime.exec("kill -9 " + myJavaProcessPID) or something of the
sort, again reached via a custom writeObject() or similar method
in a serialized class.
d) The deployment JVM has a bug, which can cause it to silently exit
with no diagnostic other than due to System.exit(), SIGABRT, or the
OS killing it without letting it run a signal handler first.
(I assume here that a normal JVM will report SIGSEGV etc. but not
SIGABRT, usually resulting from a user attempt to abort a process.
Of course, a lot of signals such as SIGSEGV themselves indicate
bugs in either the VM or JNI native code.)

These are ordered roughly by descending likelihood.

I'd catch Throwable and see if it catches anything. If not I'd then
check the custom serializable classes' serialization-related methods
for any wackiness. If nothing turned up I'd now suspect a bug in
either the VM or the native code associated with serialization, so a
JRE bug, especially if you're using a weird non-Sun JVM or an old
version. If you're compiling to native code rather than bytecodes
using e.g. Jet then it's most likely a compiler bug or some kind of
corruption that screws up signal handling so you don't get a clean
segfault dump or similar. (How well does Java-compiled-to-native-
binary-executable cope with out of memory conditions? Do these even
have garbage collection? They must, though, I'd think, since the Java
code won't have explicit memory management like free() calls...)

Of course the wisdom of having broad catches like catch (Exception) is
a whole other topic. I'm assuming that your catch (Exception) and
various System.out.printlns are all part of your debugging efforts
and, as such, are temporary. I'd leave a function like that with a
finally block to close any open streams and tack a "throws
IOException" onto the method signature once I had it working, also
catching ClassCastException and rethrowing as an IOException subclass
indicating that the file was corrupt or in the wrong format, since the
object not being a Universe is presumably a file error and should
therefore be handled as an I/O exception. There's also a class not
found error or exception readObject can throw deserving like
treatment, since an object of a class unknown to the application is
clearly not a Universe. Aside from transforming these runtime
exceptions and errors into the checked IOException I'd not catch or
handle anything in gLoadUniverse().
 
P

Patricia Shanahan

Twisted said:
I read the OP's post as indicating it is exiting without an error
message, rather than hanging. Infinite loops tend to mean hanging, or
an eventual Error due to memory use or stack overflow.

I suggested a recursive call loop, rather than any other form of loop,
partly because the symptom would be a StackOverflowError, a
non-Exception Throwable, falling in your case (a), not a permanent hang.
A symptomless exit shouldn't result from readObject() unless one of
four things is true:
a) a non-Exception Throwable is thrown (likely an Error), caught
(further up the call chain), and the handler exits silently without
dumping a stack trace. This eliminates the default
uncaught-exception handlers that come with the JRE.


Patricia
 
A

Andrew Thompson

I have this code:

This code I would call a 'snippet'. Please consider posting
compilable code in future, as it makes it much simpler for
people to help. By 'compilable', I specifically mean an
SSCCE.

Nevertheless, I would suggest a variety of changes to this
snippet, partly based on misunderstandings observed in
the thread, and partly on making it closer to an SSCCE.
public static Universe gLoadUniverse(String uvName) {

Huhh? A frickin' 'Universe'?! Try loading a Galaxy, Nebula,
Stellar System, Planet, Moon or even a plain ol' Java
*Object* successfully, before worrying about loading
one (or more) Universe's!
try {
System.out.println("I'm here");

Where's 'here'? On my box, running in Sun's JRE,
in a typical situation, that would be the 'command line'
where that string appears for me. It means little more..

OTOH
System.out.println("Start of try");
..means a little more.
ObjectInputStream ois = new ObjectInputStream(new
FileInputStream("C:/a.obj"));
System.out.println("I'm here");

And this? An identical string? Counting Strings to
find the location in the source is an horrendous idea.
I suggest instead..
System.out.println("ois: " + ois);
which is not only an unique (so far) and specific string,
but also gives us some information on that OIS. For
example, is OIS 'null'?

But I will take it further.

Code that is broken, should do only *one* thing at a
time, and it should check *each* step. This is how I
might write those two lines.

// ObjectInputStream ois = new ObjectInputStream(new
// FileInputStream("C:/a.obj"));
// TOO BIG A CHUNK!
File drive = new File( "C:" );
System.out.println("drive: " + drive + " \texists: " + drive.exists() );
// uses the correct path separator for OS
File file = new File( drive, "a.obj" );
System.out.println("file: " + file + " \texists: " + file.exists() );
FileInputStream fis = new FileInputStream(file);
System.out.println("fis: " + fis );
ObjectInputStream ois = new ObjectInputStream(fis);
System.out.println("ois: " + ois);

..obviously this would not be the way to write production
code, but this is experimental code where we are trying
to figure what is going wrong, so the extra lines/effort
make sense.

Of course, logging would be a better way to get output
at this level, and I am almost surprised that Lew has
not already taken the opportunity to extoll its virtues. ;-)

...
catch (Exception e) {

..As Patricia(?) and others have pointed out, that
does not cover Errors.
System.out.println("I'm here " + e.getMessage());
e.printStackTrace();

This is good strategy, and should usually get
the goods on what went wrong, assuming the
problem is caught, but it makes the previous line
somewhat redundant..
return null;
}
}

It prints out the first to I'm here's, but nothing else.and quits.

That seems to be beyond the point to which I
was explaining, but both recode the code in the
early part, and carry that principle through to any
other code before proceeding (I recommend).
...So
in "Universe uv = (Universe) ois.readObject();" something goes wrong,
but I don't get any feedback whatsoever.

That seems very odd, unless other code, not shown*,
is swallowing exceptions or errors - not printing them.
...Is there something else that
I may not be catching?

Error, but I don't think that, in itself, explains the
behaviour you are *not* seeing (some error output,
if nothing else). This brings me back to..
* An SSCCE that demonstrates the behaviour.
Preferably one with a 'path' String fed in main()
(that can be easily found and changed), that first
writes a simple Object, then reads it back in.
 
A

aaronfude

(e-mail address removed) wrote:

..


This code I would call a 'snippet'. Please consider posting
compilable code in future, as it makes it much simpler for
people to help. By 'compilable', I specifically mean an
SSCCE.

Nevertheless, I would suggest a variety of changes to this
snippet, partly based on misunderstandings observed in
the thread, and partly on making it closer to an SSCCE.


Huhh? A frickin' 'Universe'?! Try loading a Galaxy, Nebula,
Stellar System, Planet, Moon or even a plain ol' Java
*Object* successfully, before worrying about loading
one (or more) Universe's!


Where's 'here'? On my box, running in Sun's JRE,
in a typical situation, that would be the 'command line'
where that string appears for me. It means little more..

OTOH
System.out.println("Start of try");
.means a little more.


And this? An identical string? Counting Strings to
find the location in the source is an horrendous idea.
I suggest instead..
System.out.println("ois: " + ois);
which is not only an unique (so far) and specific string,
but also gives us some information on that OIS. For
example, is OIS 'null'?

But I will take it further.

Code that is broken, should do only *one* thing at a
time, and it should check *each* step. This is how I
might write those two lines.

// ObjectInputStream ois = new ObjectInputStream(new
// FileInputStream("C:/a.obj"));
// TOO BIG A CHUNK!
File drive = new File( "C:" );
System.out.println("drive: " + drive + " \texists: " + drive.exists() );
// uses the correct path separator for OS
File file = new File( drive, "a.obj" );
System.out.println("file: " + file + " \texists: " + file.exists() );
FileInputStream fis = new FileInputStream(file);
System.out.println("fis: " + fis );
ObjectInputStream ois = new ObjectInputStream(fis);
System.out.println("ois: " + ois);

.obviously this would not be the way to write production
code, but this is experimental code where we are trying
to figure what is going wrong, so the extra lines/effort
make sense.

Of course, logging would be a better way to get output
at this level, and I am almost surprised that Lew has
not already taken the opportunity to extoll its virtues. ;-)

..


.As Patricia(?) and others have pointed out, that
does not cover Errors.


This is good strategy, and should usually get
the goods on what went wrong, assuming the
problem is caught, but it makes the previous line
somewhat redundant..



That seems to be beyond the point to which I
was explaining, but both recode the code in the
early part, and carry that principle through to any
other code before proceeding (I recommend).


That seems very odd, unless other code, not shown*,
is swallowing exceptions or errors - not printing them.


Error, but I don't think that, in itself, explains the
behaviour you are *not* seeing (some error output,
if nothing else). This brings me back to..
* An SSCCE that demonstrates the behaviour.
Preferably one with a 'path' String fed in main()
(that can be easily found and changed), that first
writes a simple Object, then reads it back in.

Thanks for all responses. It was an Error - Out of memory.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top