1 2 3 Previous Next 34 Replies Latest reply: Jul 1, 2011 6:05 PM by jschellSomeoneStoleMyAlias Go to original post RSS
      • 30. Re: Why does Exception allows Throwable as a cause
        EJP
        I guess, no one has ever come across a situation when they would wrap an Error in an Exception.
        I guess you're not reading your own thread. jtahlborn provided one in the first reply. The rest of us rejected the terms of your question, and put the onus back on you to show why it shouldn't be allowed.

        I guess you don't have any actual reasons.
        And there is no good reason (please dont honk your horns if I may say so) behind allowing a Throwable as a cause.
        There is no good reason not to, and the art of API design is to provide mechanism, not policy.
        • 31. Re: Why does Exception allows Throwable as a cause
          jschellSomeoneStoleMyAlias
          jverd wrote:
          jschell wrote:
          jverd wrote:
          If you're saying that when I call new java.util.X(), and that ends up 5 layers deeper calling new java.lang.Y(), that you're considering X's call to new Y() as part of the JVM, I certainly don't consider that the case. If those calls fail, then the JVM--the executable that is managing my app--has no reason to be corrupt. An OOME will be generated and propagate up to my code, which will continue to propagate it until it's (presumably) caught by catch Throwable at an architectural boundary. My app may or may not be able to recover, but there's no reason to think the environment in which it's running is corrupt.

          If the 5-layer-deep call to new java.lang.Y() ends up with the JVM unable to malloc() for its own bookkeeping, even though there may be enough heap left for my objects, then I wouldn't expect OOME, or if I got it, only if the JVM was still in a coherent state.

          In short, since the JVM manages my app's memory, I should only get an OOME, with control returning to my app, if the problem is entirely within my app, but not within the JVM. Again, I may be mistaken here, but I think it's a reasonable assumption. I welcome any authoritative doc that refutes it though.
          Not sure that is true although it might depend on what you mean.

          If you attempt to allocate a large number of threads I believe you get a OOME. Not because you are out of memory but rather because you are out of a native resource associated with threads which means no more can be created.

          Permgen errors also cause OOMEs too.

          Both of those would seem internal to the VM but the OOME results.
          Fair enough. I wouldn't expect any of those cases to leave the VM in a corrupt state though.
          I wouldn't either. Almost sure they don't.
          • 32. Re: Why does Exception allows Throwable as a cause
            jschellSomeoneStoleMyAlias
            yogesh wrote:
            >
            "We want to be able to construct an exception that indicates some other exception as the underlying cause."
            >

            Thats exactly my point. Error's are not exceptions. The design gives a suggestion that it is OK to wrap Throwables that are not exceptions. There is a conceptual difference between Exceptions and Errors (otherwise we wouldn't need a different branch in the throwable hierarchy just for Errors.
            I provided exactly a case for that.

            I have a plugin system. Keep it simple with a GUI designer that allows me to plug in graphic components. I drag and drop a new 'shape' onto a canvas.

            I install a new shape. My GUI, in the load layer attempts to load it. I get a AbstractMethodError because the plugin is wrong. My layer catches it. Because I expect plugins to be messed up. I wrap it because the caller of the load layer expects a normal exception when a plug in fails. It presents an message box to the user telling them something (what is irrelevant) and continues. The alternative, exiting immediately, means that the canvas the user has been working on for hours is lost.


            >
            >
            "Honestly, I think you're making a mountain out of a molehill here."
            >

            Well I still can't think of a business requirement for this.
            I write 24x7 servers for a living that always use plugins. The server can't exit because a plugin doesn't load. There are 30 or 100 other functional business aspects of the server than can continue to run even if a single plugin fails.
            • 33. Re: Why does Exception allows Throwable as a cause
              796440
              jschell wrote:
              I install a new shape. My GUI, in the load layer attempts to load it. I get a AbstractMethodError because the plugin is wrong. My layer catches it. Because I expect plugins to be messed up. I wrap it because the caller of the load layer expects a normal exception when a plug in fails. It presents an message box to the user telling them something (what is irrelevant) and continues. The alternative, exiting immediately, means that the canvas the user has been working on for hours is lost.
              And, in case the OP doesn't see the connection to the end of the trail--his question of why Error is allowed as the cause of a wrapping exception--now that we've caught the Error, in addition to giving the caller a "normal exception" and presenting a message box to the user, we (the developers of this system) may still want a record of what went wrong and why. Now that we've passed the Error in the cause parameter to our wrapping exception's c'tor, we have that information available to us.
              • 34. Re: Why does Exception allows Throwable as a cause
                jschellSomeoneStoleMyAlias
                yogesh wrote:
                I think the discussion has gone way ahead. Thanks everyone for their valuable comments.

                Although I never meant to suggest "Because I feel It shouldn't be allowed, they should remove it".

                My question was basically to find out the actual reason for allowing it.
                The Java API is a general purpose library.

                Libraries in general should not be written specifically for one application. And a library like the Java API cannot be written even to support a single business domain.

                Eclipse, JBoss and even the Sun java compiler are all written in java and they are targeting vastly different business domains. The Java API must be written in such way that provides the best efficiency, ease of use as well as an interface (general not java term) that supports such a wide range of uses.

                That is a goal and as such it often fails but it is still a goal.

                And thus for your question it is not whether it is likely but rather whether it is possible that such a situation could arise. It can. It does. And the design does not affect other aspects either.


                >
                I guess, no one has ever come across a situation when they would wrap an Error in an Exception. And there is no good reason (please dont honk your horns if I may say so) behind allowing a Throwable as a cause.
                I certainly have.

                I ALWAYS catch Throwable (not exception) at boundary layers. At least as a last chance handler. The contract of the layer I am working in and the specific method that I am working with dictates the error processing of that I implement. And these days if I don't log the originating exception and I don't specifically know the cause then I wrap it in something else and throw it.
                1 2 3 Previous Next