Tag Info

New answers tagged

1

It depends on what that string you're passing in actually does. For this answer, I'm going to assume that string is a "scope prefix", i.e. a string that simply gets printed out at the beginning of every log message output via this logger to make it clear where it comes from, because that's how every logger I've ever worked with did things (if it does do ...


3

The rule of thumb when it comes to logging: "it's never too late!" Do you think it is advisable to try to add logging to this program now? Or do you think that I'm too far along to try to fix this problem? You can start off with some generic logging, which is agnostic to your application as such: ENTRY/EXIT logs: You can add a logging statement ...


1

I'd suggest reading up on Aspect-Oriented Programming, specifically as it applies to logging: http://www.yegor256.com/2014/06/01/aop-aspectj-java-method-logging.html AOP is a technique for keeping your methods clean and focused on business logic while extracting "plumbing" code - such as security, validation or, yes, logging - to external classes, and ...


3

Maintain a map in which you accumulate function names and associate them with unique integer ids. You should be able to optimize the performance of the map by taking into consideration the fact that the function name produced by the compiler for a certain function will always have the same address. (There will be only one string constant per function name ...


1

You could use __LINE__ instead, and although the function names will no longer be present in your logs, you can easily resolve them when analysing the logs. An alternative is a static object in each function, declared at the start, that wraps trhe logger functions so you use it to write the log lines. The constructor would store a code (eg the line number ...


0

So here, you're writing the handler that throws the exception and the grid manages that exception itself. I see this as fair enough - after all, you're writing the library code that throws on error states, and the caller (ie the grid) catches and manages the exception how it likes, in this case showing a message to the user in a dialog (which is perfectly ...


2

Since the .NET framework standard UI controls do not catch unhandled exceptions by themselves, and offer you some mechanisms to catch those exceptions in a central place, I agree that it is questionable why a 3rd party control should behave differently. Lets assume, from the nature of your application, in case of a severe failure, you are 100% sure you can ...


1

I am very fond of hard error & fail fast, I believe they are the one true and right way to go, but I try not to be dogmatic about them. There are cases where the best thing to do with an unexpected exception is to log it and swallow it. I will give you an example which is more simple than your situation: suppose you have an observable collection which, ...


1

I recently solved a similar problem with a third-party library. Allow me to restate to make sure I'm not misinterpreting your situation. You know how to work around it, but you don't like the repetition of the workaround, and you feel it obscures your actual code? I solved my problem using a python decorator that catches an exception and handles it ...


2

What is there to do. In my view, the decision to turn an exception during validation into a failed validation is a correct way of handling such exceptions. Letting the exception pass through and crash the application has a significant risk that you lose the work the user had been doing, even if the situation was caused by bad user-input and entirely ...


4

If the system 2 handles the exception and doesn't rethrow it, then it sounds like system 1 doesn't have any way of knowing that an exception occurred. In that case, there's really no question as to whether system 1 should log anything, since it doesn't know an error occurred! If both systems are aware of the error, and they are logging to different places, ...


0

It depends on the exception. If you expect that the exception may occur and it is valid, and you are actually handling it, as in, you've got plan B for that situation, then don't throw it. If the exception breaks the workflow and you aren't actually handling it, go ahead and log it if you deem it necessary, but sometimes the current method scope doesn't ...


1

You could argue that they should both log it. System 1 is trying to accomplish something but needs to access System 2. System 1 should log that it couldn't successfully complete its work for some reason or another due to its dependency on System 2. If System 2 encounters an internal error processing a request, it should be logging those types of issues ...



Top 50 recent answers are included