John Embretsen wrote: > Bryan Pendleton wrote: >> > Kristian Waagan commented on DERBY-1471: >> > ---------------------------------------- >> > >> > The approach is to exhaust the application stream and copy it into >> > memory to determine the length. If the data is too big to fit in >> memory, >> > the client will fail with an out-of-memory exception. >> >> That seems fine to me. This is already the case with the current >> API and implementation, I believe, so we aren't making anything worse. > > Hi Kristian and Bryan, > > I am assuming that there is no out-of-memory specific exception > implemented in Derby, and that you by "out-of-memory exception" mean > java.lang.OutOfMemoryError. Please give me a hint if my assumption is > wrong...
Hello John, There is no java.lang.OutOfMemoryException, but there is an out-of-memory exception - the unchecked exception class OutOfMemoryError, which is also referred to as an error class! I'll follow your advice and use the term out-of-memory error, which is much more precise :) > > I believe it is important to distinguish between java Errors and > Exceptions, since an Error "indicates serious problems that a reasonable > application should not try to catch" [1]. > > I agree. According to the "The Java Language Specification, Third Edition", the reason why errors are not checked exceptions is "... they can occur at many points in the program and recovery from them is difficult or impossible. A program declaring such exceptions would be cluttered, pointlessly."*. Cheers, -- Kristian * 11.2.4, page 301
