Some Java Questions

[*IslamicGirl*]

In the name of Allah, the MOst Merciful, the Most Kind

:salam:


I'm trying to answer some Java questions as i have an exam on Monday on it :p

And there are some questions i'm unsure of like:


1) Explain why EXCEPTIONS play an important role in JAva File handling (6 mark)


2) Explain the difference between text and binary files in Java ( 6 marks)


I could get a few marks with the definition, but how do i expand on them to get 6 marks?

Two marks will prob be for a definition and two marks for an example but what else could i say for two more marks?


JazakhAllahu Khair


:wswrwb:

[Eyyub]

:wswrwb:


(What a weird questions).

The answers may be this:

1) with exceptions in File Handling in Java, you can catch some weird stuff like:
-filename/path does not exist (NullpointerExc).
-SecurityExc. when some paths cannot be accessed (due to permission restrictions; e.g. in Applets or in Sockets etc.)

Also using exc. errors can be found and processed in a consistent way. Otherwise, programmer must handle many possible errors by themselves. Without Exc., normally return values are used to indicate the occurance of errors. But check return value is tedious and if programmers forget to check them, the program will be crashed easily.

2) Text files are just character streams and binary are just 0 1 streams. They are also processed differently.


Just remember that these answers may be totally wrong. You should look into your textbook for more information.

(Fortunatelly I dont have to do this kind of exams anymore :D )

Wassalaam.

[*IslamicGirl*]

In the name of Allah, the MOst Merciful, the Most Kind

:salam:

JAzakhAllah Khair :)


The text book provides some answers but def not enough to cover the 6 marks, which is strange as i've looked at the lecturers notes and he doesn't have much on it either.

Maybe he's expecting two examples instead of the common one answer.

:wswrwb:

[theOverMind]

Just wanted to add this to the thread if I may.

For technical definitions WikiPedia and Webopedia are your friends. For this particular thread here are the two links:-
http://en.wikipedia.org/wiki/Binary_file
http://en.wikipedia.org/wiki/Exception
(Don't worry about being java-centric; Exceptions serve the same purpose for all high- & higher-level languages).

[Red Bug]

Assalamalaikum wr wb,

This might be very helpful:

First question: http://java.sun.com/docs/books/tutorial/essential/exceptions/advantages.html
you can use the code given in the start as an example to prove the advantages too.

Second Question:
http://forum.java.sun.com/thread.jspa?threadID=624106&start=0

wasalamalaikum wr wb

[Eyyub]

Assalamalaikum wr wb,

This might be very helpful:

First question: http://java.sun.com/docs/books/tutorial/essential/exceptions/advantages.html
you can use the code given in the start as an example to prove the advantages too.

Second Question:
http://forum.java.sun.com/thread.jspa?threadID=624106&start=0

wasalamalaikum wr wb

An excellent link ! -I think the answers for the questions in post 1 are
answered now.

However, I just wanna notice you all that there has been a lot of debate lately
about the use of exceptions in Java, especially about [when to use] checked-exceptions.

Here is an article about this topic (an excerpt from chapter 4 of the book:
"Expert One-on-One J2EE Design and Development"):



Exception Handling – Checked or Unchecked Exceptions

Java distinguishes between two types of exception. Checked exceptions extend java.lang.Exception, and the compiler insists that they are caught or explicitly rethrown. Unchecked or runtime exceptions extend java.lang.RuntimeException, and need not be caught (although they can be caught and propagate up the call stack in the same way as checked exceptions). Java is the only mainstream language that supports checked exceptions: all C++ and C# exceptions, for example, are equivalent to Java's unchecked exceptions.

First, let's consider received wisdom on exception handling in Java. This is expressed in the section on exception handling in the Java Tutorial
(http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html), which advises the use of checked exceptions in application code.

Note
Because the Java language does not require methods to catch or specify runtime exceptions, it's tempting for programmers to write code that throws only runtime exceptions or to make all of their exception subclasses inherit from RuntimeException. Both of these programming shortcuts allow programmers to write Java code without bothering with all of the nagging errors from the compiler and without bothering to specify or catch any exceptions. While this may seem convenient to the programmer, it sidesteps the intent of Java's catch or specify requirement and can cause problems for the programmers using your classes

Checked exceptions represent useful information about the operation of a legally specified request that the caller may have had no control over and that the caller needs to be informed about – for example, the file system is now full, or the remote end has closed the connection, or the access privileges don't allow this action.

What does it buy you if you throw a RuntimeException or create a subclass of RuntimeException just because you don't want to deal with specifying it? Simply, you get the ability to throw an exception without specifying that you do so. In other words, it is a way to avoid documenting the exceptions that a method can throw. When is this good? Well, when is it ever good to avoid documenting a method's behavior? The answer is "hardly ever".


To summarize Java orthodoxy: checked exceptions should be the norm. Runtime exceptions indicate programming errors.

I used to subscribe to this view. However, after writing and working with thousands of catch blocks, I've come to the conclusion that this appealing theory doesn't always work in practice. I'm not alone. Since developing my own ideas on the subject, I've noticed that Bruce Eckel, author of the classic book Thinking in Java has also changed his mind. Eckel now advocates the use of runtime exceptions as the norm, and wonders whether checked exceptions should be dropped from Java as a failed experiment (http://www.mindview.net/Etc/Discussions/CheckedExceptions).

Eckel cites the observation that, when one looks at small amounts of code, checked exceptions seem a brilliant idea and promise to avoid many bugs. However, experience tends to indicate the reverse for large code bases. See "Exceptional Java" by Alan Griffiths at http://www.octopull.demon.co.uk/java/ExceptionalJava.html for another discussion of the problems with checked exceptions.

Using checked exceptions exclusively leads to several problems:

Too much code
Developers will become frustrated by having to catch checked exceptions that they can't reasonably handle (of the "something when horribly wrong" variety) and write code that ignores (swallows) them. Agreed: this is indefensible coding practice, but experience shows that it happens more often than we like to think. Even good programmers may occasionally forget to "nest" exceptions properly (more about this below), meaning that the full stack trace is lost, and the information contained in the exception is of reduced value.

Unreadable code
Catching exceptions that can't be appropriately handled and rethrowing them (wrapped in a different exception type) performs little useful function, yet can make it hard to find the code that actually does something. The orthodox view is that this bothers only lazy programmers, and that we should simply ignore this problem. However, this ignores reality. For example, this issue was clearly considered by the designers of the core Java libraries. Imagine the nightmare of having to work with collections interfaces such as java.util.Iterator if they threw checked, rather than unchecked, exceptions. The JDO API is another example of a Sun API that uses unchecked exceptions. By contrast, JDBC, which uses checked exceptions, is cumbersome to work with directly.

Endless wrapping of exceptions
A checked exception must be either caught or declared in the throws clause of a method that encounters it. This leaves a choice between rethrowing a growing number of exceptions, or catching low-level exceptions and rethrowing them wrapped in a new, higher-level exception. This is desirable if we add useful information by doing so. However, if the lower-level exception is unrecoverable, wrapping it achieves nothing. Instead of an automatic unwinding of the call stack, as would have occurred with an unchecked exception, we will have an equivalent, manual, unwinding of the call stack, with several lines of additional, pointless, code in each class along the way. It was principally this issue that prompted me to rethink my attitude to exception handling.

Fragile method signatures
Once many callers use a method, adding an additional checked exception to the interface will require many code changes.

Checked exceptions don't always work well with interfaces
Take the example of the file system being full in the Java Tutorial. This sounds OK if we're talking about a class that we know works with the file system. What if we're dealing with an interface that merely promises to store data somewhere (maybe in a database)? We don't want to hardcode dependence on the Java I/O API into an interface that may have different implementations. Hence if we want to use checked exceptions, we must create a new, storage-agnostic, exception type for the interface and wrap file system exceptions in it. Whether this is appropriate again depends on whether the exception is recoverable. If it isn't, we've created unnecessary work.

Many of these problems can be attributed to the problem of code catching exceptions it can't handle, and being forced to rethrow wrapped exceptions. This is cumbersome, error prone (it's easy to lose the stack trace) and serves no useful purpose. In such cases, it's better to use an unchecked exception. This will automatically unwind the call stack, and is the correct behavior for exceptions of the "something went horribly wrong" variety.

I take a less heterodox view than Eckel in that I believe there's a place for checked exceptions. Where an exception amounts to an alternative return value from a method, it should definitely be checked, and it's good that the language helps enforce this. However, I feel that the conventional Java approach greatly overemphasizes checked exceptions.

Important
Checked exceptions are much superior to error return codes (as used in many older languages). Sooner or later (probably sooner) someone will fail to check an error return value; it's good to use the compiler to enforce correct error handling. Such checked exceptions are as integral to an object's API as parameters and return values.

However, I don't recommend using checked exceptions unless callers are likely to be able to handle them. In particular, checked exceptions shouldn't be used to indicate that something went horribly wrong, which the caller can't be expected to handle.

Important
Use a checked exception if calling code can do something sensible with the exception. Use an unchecked exception if the exception is fatal, or if callers won't gain by catching it. Remember that a J2EE container (such as a web container) can be relied on to catch unchecked exceptions and log them.

I suggest the following guidelines for choosing between checked and unchecked exceptions:



|Question|--------------|Example|------------|Recommendation if the answer is yes|

Should all callers handle -- Spending limit exceeded -- Define and used a checked
this problem? Is the -- in a processInvoice() -- exception and take advantage of
exception essentially a -- method -- Java's compile-time support.
second return value for the
method?


Will only a minority of -- JDO exceptions -- Extend RuntimeException. This
callers want to handle this -- leaves callers the choice of
problem? -- catching the exception, but doesn't
-- force all callers to catch it.

Did something go horribly -- A business method fails -- Extend RuntimeException. We
wrong? Is the problem -- because it can't connect -- know that callers can't do anything
unrecoverable? -- to the application -- useful besides inform the user of
-- database -- the error.

Still not clear? -- Extend RuntimeException.
-- Document the exceptions that may
-- be thrown and let callers decide
-- which, if any, they wish to catch.




Important
Decide at a package level how each package will use checked or unchecked exceptions. Document the decision to use unchecked exceptions, as many developers will not expect it.

The only danger in using unchecked exceptions is that the exceptions may be inadequately documented. When using unchecked exceptions, be sure to document all exceptions that may be thrown from each method, allowing calling code to choose to catch even exceptions that you expect will be fatal. Ideally, the compiler should enforce Javdoc-ing of all exceptions, checked and unchecked.

If allocating resources such as JDBC connections that must be released under all circumstances, remember to use a finally block to ensure cleanup, whether or not you need to catch checked exceptions. Remember that a finally block can be used even without a catch block.

One reason sometimes advanced for avoiding runtime exceptions is that an uncaught runtime exception will kill the current thread of execution. This is a valid argument in some situations, but it isn't normally a problem in J2EE applications, as we seldom control threads, but leave this up to the application server. The application server will catch and handle runtime exceptions not caught in application code, rather than let them bubble up to the JVM. An uncaught runtime exception within the EJB container will cause the container to discard the current EJB instance. However, if the error is fatal, this usually makes sense.

Important
Ultimately, whether to use checked or unchecked exception is a matter of opinion. Thus it's not only vital to document the approach taken, but to respect the practice of others. While I prefer to use unchecked exceptions in general, when maintaining or enhancing code written by others who favor exclusive use of checked exceptions, I follow their style.