Timeline for Custom error-logging
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 4, 2018 at 6:20 | comment | added | Flater | @t3chb0t: [..] This boils down to what I said earlier: a good library gives the user control over how things should be handled (which NLog does, through its massive configurability), and doesn't make fixed decisions for the user (having a simpler configuration would effectively remove some options just to make things easier to read - form over function is not a good thing for a library). | |
| Jun 4, 2018 at 6:18 | comment | added | Flater | @t3chb0t: I have yet to come across a situation where NLog couldn't handle my desired log structure. I do agree that if you're looking for a straightforward dump to a file, NLog takes more configuration as opposed to e.g. a File.WriteAllLines (as a basic example); but once you get into multi-file logging, NLog's configuration is not overkill. There are simply so many different approaches to logging. A more terse configuration would simply not be able to cater to all the approaches (or offer a desirable level of configurability). [..] | |
| Jun 4, 2018 at 6:10 | comment | added | t3chb0t | I wouldn't get over-exiced about NLog or any other logger. They are missing planty of features and their configuration is not that pretty either. From my point of view there hasn't been a single case where I hadn't to customize or rather hack them in order to get the job done. If I only had the time to write my own tool... it's good to know about them but they are not the right tool for everything. | |
| Jun 4, 2018 at 5:55 | history | edited | Flater | CC BY-SA 4.0 | added 2 characters in body |
| May 19, 2018 at 18:18 | comment | added | piedar | @KelsonBall That's why you're supposed to always await tasks, and why async void is dangerous except in an event handler. | |
| May 18, 2018 at 15:12 | comment | added | Kelson Ball | @Flater from the research I've done and experience developing, asynchronous code doesn't throw the exception until the task result is inspected. The debugger can't break on an exception that hasn't been thrown. Async Task does not return a result, so asynchronous io writes (for example) swallow exceptions unless you catch-and-break or return a 'success' value to inspect. Both involve changing the code to support debugging. Is there a way to change that behavior of the runtime so asynchronous exceptions are thrown immediately? | |
| May 18, 2018 at 14:44 | comment | added | piedar | I should have been more precise. The example "a" + "b" + "c" + "d" compiles down to "abcd" because string literals can be combined at compile-time. | |
| May 18, 2018 at 11:54 | comment | added | Thomas Ayoub | @Flater I understand. I think that my english is not rich enough to explain what my though really are unfortunately. | |
| May 18, 2018 at 10:13 | comment | added | Flater | @ThomasAyoub: Incorrect as it may be, that is what my answer initially stated. If you reread my comment, you'll see that I'm actually stating that piedar's comment is a correct counter to my wrong answer. I simply don't understand what your comment is adding that wasn't already said by piedar. | |
| May 18, 2018 at 10:01 | comment | added | Thomas Ayoub | @Flater it doesn't do step by step allocation in OP's case. It would have if OP used someting like var s = "a"; s+= "b"; s+= "c" which is not the case here. | |
| May 18, 2018 at 9:56 | comment | added | Flater | @ThomasAyoub: What you say is correct, but how is it meaningfully different from what piedar said? he already mentioned the array approach (as did his linked post). The only way I can see that this makes a difference is that an array needs to be allocated (mentioned in the linked post); but this is still dramatically more performant than allocating every (step-by-step) concatenated string separately, which is what I was pointing out in my answer. Note that this isn't (just) related to concatenating all the string elements, but rather having to allocate all the intermediate steps as well. | |
| May 18, 2018 at 9:53 | comment | added | Thomas Ayoub | @piedar this is a bit more complicated. var s = "a" + "b" + "c" will be optimized to one and only allocation by the compiler. But var s = "a" + foo.ToString() + "b" + bar.ToString() + "c" + foobar.ToString() will result in String.Concat([...]) | |
| May 18, 2018 at 8:29 | comment | added | Flater | @KelsonBall: During debug, Exceptions are caught (if you've configured VS to break on those exceptions), which also allows you to inspect the exception (by clicking "View Detail..."). While I do agree that all developers do it from time to time, writing code specifically for debugging purposes is not ideal. Since there's a way to achieve the same thing without writing debugging code (thus reducing nesting); I'm advocating for that way instead, even if only as a point of principle. Your method is not wrong; but I do think mine leads to cleaner code overall. | |
| May 18, 2018 at 8:27 | history | edited | Flater | CC BY-SA 4.0 | added 580 characters in body |
| May 18, 2018 at 8:21 | comment | added | Flater | @piedar: Interesting. Do you know since when was this implemented? Because I made the same + mistake in the past and the memory usage was massive. I've seen the issue occur; so I would assume that this was fixed at some point after that? | |
| May 18, 2018 at 1:06 | comment | added | GMB | @flater Thank you for your input and feedback. | |
| May 18, 2018 at 1:05 | vote | accept | GMB | ||
| May 17, 2018 at 17:29 | comment | added | piedar | The warnings against the performance of string concatenation are unfounded. The compiler optimizes the + operator to String.Concat(), which uses a StringBuilder internally. In other words, "a" + "b" + "c" + "d" is equivalent to String.Concat(new[] { "a", "b", "c", "d" }). | |
| May 17, 2018 at 16:49 | comment | added | Kelson Ball | Catching and throwing does have a purpose during debugging if you need to inspect the exception within a context that swallows it or otherwise makes it difficult to find - such as in async code where the task result is not checked. | |
| May 17, 2018 at 9:17 | history | edited | Flater | CC BY-SA 4.0 | deleted 14 characters in body |
| May 17, 2018 at 9:17 | comment | added | Abbas | +1 Great review, nice that you mentioned to not reinvent the wheel! :) | |
| May 17, 2018 at 9:16 | history | answered | Flater | CC BY-SA 4.0 |