Are exceptions excluded from a single element?

Question

A presentation of static factory methods (directly from Effective Java) was presented at my college of work, and then an example of its use for receiving static / single exceptions is given.

I chose a red flag. Are exceptions ruled out? Aren't they populated by the JVM for stack trace information? What savings do you really get from this, since exceptions should only occur for exceptional situations?

My knowledge of exceptions is quite limited, so I come to you with this: will exceptions from the same syntax be executed and are there any reasons for using them?

Answer 1

Exceptions to Singleton should be performance optimization. The idea is that you eliminate the cost of filling the stack trace when creating an exception, which is usually the most expensive part of the exception.

If the exception were unique and descriptive enough, and stacktrace was not going to be used, then the singleton could potentially be effective. You can create an application so that a specific type of exception with a specific message always means that the exception was created from a specific location. Then the stack trace does not matter.

April 22, 2003 The Tips for Technical Issues article describes a scenario for reusing an exception. In this case, they try to run the garbage collector, reducing the number of objects created. If you missed the call to populateStackTrace() , you don’t have to worry about streaming.

In general, if the impact of an exception is causing problems, this is a sign that exceptions are used for application logic, and an error code should be used instead.

In the new JVM (1.4+, I believe) this "optimization" can be performed using the JVM when running in "-server" mode. This hot spot optimization can be controlled by the -XX:+OmitStackTraceInFastThrow .

Personally, I would recommend not using the singleton exception [anti-] pattern.

Answer 2

Although I disagree with this approach, Singleton Exceptions can work in a single-threaded environment.

People who offer Singleton Exception templates are typically used for the old c-style call / error / error paradigm and want to translate this into one of these new “object-oriented” languages.

It is possible, but I call it the smell of code.

Answer 3

I can imagine a situation where you want to detect exceptions in your conditions if an exception has already been created by another part of your application; I can see the use of a singleton exception for this purpose; but it seems redundant. Essentially, it combines the idea of ​​a semaphore (“something happened”) with the Exception (“something happened to ME”).

Answer 4

If the "static factory method" returns the same object, it is not really a factory method.

Even java.lang.Throwable has two mutable state elements: a stack trace and an initial reason until a new version of Java adds more. Any generic Throwable will either have to terminate the fillInStackTrace contract or behave very strangely. In addition, reusable Throwable cannot intelligently change the message.

So you could get away with it, but want to? Almost all performance issues (and you usually shouldn't throw exceptions too often) go down to fillInStackTrace . If you hit this, then reuse is of little use.

(I prefer the expression "static create method" to "static factory method" because "factory" is too overloaded.)