Tag Info

New answers tagged

0

Logging asynchronously is the only way to go if you need low-latency in the logging threads. The way this is done for maximum performance is through the disruptor pattern for lock-free and garbage-free thread communication. Now if you want to allow multiple threads to log concurrently to the same file you must either synchronize the log calls and pay the ...


2

Log4j, at least, has both. The methods with just the log level name such as logger.debug(...) are convenience methods that simply call logger.log(DEBUG, ...). You can read more about this at the Custom Log Levels documentation page: Convenience Methods for the Built-in Log Levels The built-in log levels have a set of convenience methods on the ...


1

I would say that a logger should never fail, but what if, for some reason, it does anyway? That makes in your scenario no sense: try do x log('successful') catch log('fail') end If your first logger fails, an exception is thrown and you are going to the catch block. But if the logger fails in the first place, it would do so in the second ...


3

First of all, you have to ensure that logging never throws any exceptions. It's better not to log one message than breaking program logic by it. Besides that, your second code in case of a success would log: "successful" but an error would log 2 messages: "fail" "successful" I think it's not what you want, so a first example is the way to go.


1

To answer your question you really need to answer the following: would you treat a log call failure as a failure of the whole try block? If yes, then it belongs in there. Otherwise, it should be placed outside. The bigger idea is to manage granularity of the try blocks, so that you catch right set of exceptions.


0

I would look for a way to detect the duplicates inside your code, check it at various levels of abstraction, and log when it occurs. You could require a sequence number be submitted with each job, or attach a timestamp to a job, or check a hash. That way if you detect a duplicate at layer 3, but not layer 2, you've narrowed down your search criteria. The ...


4

Assuming you've already checked the default logs for exceptions ... Explain the problem to your debug duck. When it stares at you blankly, go into more detail. Tell the duck how it's supposed to work. If the stupid duck is still staring at you blankly, go into more detail about how it's supposed to work. As you explain each component and interaction, ask ...


1

When I hit a really painful real-world problem, sometimes it helps to escape to a land of make-believe where absurd assumptions can be made - and then work backwards from this more pleasant world. So, let's remodel your problem as one that...well, sucks less to have to deal with. Let's say you know that the next time this function runs and someone tries to ...


0

In rough order of difficulty: Recall that the error may be out of your system. Maybe some person in accounting submitted the same label 10 times. Debug the database it came from, etc. Sometimes when you debug a unit test, it can take you hours to realize there's a typo in your test data. Honestly reading your problem my suspicion is your components ...



Top 50 recent answers are included