Why is magazine and toss considered an anti-pattern?

Question

This question was caused by a discussion of this article , where I did not get any good answers.

Why do you need to register your exception and then rebuild it (preserving the original stack trace, of course), be a bad idea if you cannot handle it otherwise?

Answer 1

I guess the answer is largely due to why you catch it if you can't handle it? Why not let anyone handle it (or who has no choice but to deal with it) write it down if they think it's journalistic?

If you catch it and write it down and then flip it over, then there is no way for the upstream channel code to know that you have already registered an exception, and therefore the same exception can be registered twice. Or, even worse, if all the code upstream matches the same pattern, an exception can be logged an arbitrary number of times, once for each level in the code that decides to catch it, log it, and then throw it back.

Also, some may argue that, because throwing and trapping exceptions are relatively expensive operations, all this interception and re-intrusion does not help your performance at runtime. It also does not help your code in terms of brevity or maintainability.

Answer 2

A log throw is a good template if an object catching and reconstructing an exception has reason to believe that it contains information that will not be logged further in the call stack - at least not in the most desirable way. This can lead to two reasons:

• An exception can be detected and recovered at the application layer boundary and may contain privileged information. It would be bad if the database level allowed excluding the statement, for example. "Try adding a duplicate key" fnord "in the" users "field to access the external layer of the application (which, in turn, can provide it to the user), but it may be useful for the internal parts of the database to choose such an exception and application interface so that catch it, safely register it, and restore a slightly less descriptive exception.
• An exception may be that the outer layer is likely to be waiting for processing without logging, but the inner layer may know something that the outer layer does not, which may suggest that logging may be useful. As a crude example, you can program a middle tier application to try connecting to one server, and if that doesn't work, try another. Flooding the application log with the message “failed” when the server is running for maintenance may not be practical, especially since everything works fine from the point of view of the application. It may be useful to redirect information about a connection failure to a server-related logging resource, which can then filter logs to generate a report of when the server was rising and falling, unlike the log of each connection attempt,

Answer 3

I think the simplest reason is that you usually have one top-level handler that does this for you, so there is no need to pollute the code with this exception handling.

The argument for cross-cutting arguments is basically that it is a waste of time for errors that do not concern you. It is much better that the error starts the call stack until the appropriate handler is found.

In my opinion, the only time you have to catch an exception is you can do something useful with the results. Just catching a log is not useful, because you can centralize this work further.

Answer 4

The IMO Journal and Throw is a clear violation of the Least Surprise Principle.

If the exception is handled properly at the top of the call stack, it may not be worth the error log entry at all. And then the search for the error log entry confuses.