|
W∴ Balboos wrote: On the other hand, undefined index, a real error, is also there. That can be fixed. How many copies of that message ought you keep? More than one is ludicrous. Not if troubleshooting the cause requires several examples in order to see a pattern, assuming you're logging more detail about the error than just the error number/message/location, or need to see if it only occurred once or several times but only at certain times of the day, etc.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
OK - you check the errors, discern the pattern, fix the problem.
Of what use, now are the individual errors? Instead, an explanation of what was done and why is far more useful - especially if in the vicinity of where the fix was made.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Now that the problem is fixed? Of no use at all. At this point I delete the email or event log and move on. If I'm keeping a journal of errors and fixes, which is what you seem to be calling a log, then I'll also note the problem and fix, and sure, one journal/log entry per problem is sufficient for journaling.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Don't make eye contact. Just back away slowly. No sudden movements.
My plan is to live forever ... so far so good
|
|
|
|
|
You are talking about code changes. The survey is talking about errors that happen when your code is running. You seem to be missing something in translation.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
If you never run the code it never has errors.
The survey asks how one logs errors. So - when an error occurs, it's either a code error, needs to be fixed and logged/documented/tattooed on your foreskin. If, on the other hand, it's a general error (like a user error), logging it will help nothing.
Either it gets prevented (code fix or kill user), or ignored because you cannot outwit stupid.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It seems I, and a couple of others, do not understand what you are saying in reference to the survey. But I trust it makes sense in your head.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
You say tomato - I say potato.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Exactly!
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
But it's a cucumber!
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
just for VB developers? On Error Resume Next
|
|
|
|
|
I once knew someone who had this in almost each of his methods as the first line...
|
|
|
|
|
Well, it was easier (vb6) than On Error Goto ErrorHandlerX where you probably would have returned back to the error source anyway. Or course, it should be followed up as quickly as possible with On Error Goto 0 . I wouldn't expect to see this in VB.Net though where Try/Catch is available. Are people still using this directive?
"Go forth into the source" - Neal Morse
|
|
|
|
|
Oh yes I am talking about the VB6 time in the 90's.
Since .net I didn't have much contact with visual basic. All companies I worked for since then all switched to C#, so I can't tell whether it is still used today.
|
|
|
|
|
We have multiple schemes, some do it via file logging and some use kafka broker to log and then it can be visualized using Kibana
|
|
|
|
|
You have to track for unusual activities, warning and error in your logs and send email to administrator to investigate. Most companies dun track their logs, that's why many intruders can stay undetected on their servers for many years.
|
|
|
|
|
Quote: Errors? My applications don't produce errors!
Klingon software is always on the offensive; there is no need of logs when your users have been exterminated.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Klingon Programmer — Software Development
Quote: By filing this bug you have questioned my family honour. Prepare to die!
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
We developed our own logging system containing the standard levels from debug to fatal.
The logging System is cross-plattform and logs to a local logging database (ios, android, windows).
Each log level has a retention time (verbose/debug 24 hours, info, warn 96 hours, error 168 hours, fatal forever). a client-side cleanup job that runs every 1000 log lines does a background delete of all outdated entries, thus making the db log more or less a ring buffer.
It is purely appender-based, and for the windows platform we have local log appenders, eventlog appender (windows eventlog, logs only errors and fatals) as well as a serverappender, which logs errors and fatals to a central serverside log database so the monitoring system can catch them.
For debugging we have console appender, file appender, etc.
Each appender has its own log level, so we can set up the eventlog appender to level "error", which means, it will only trigger for log events of error or above, while the console appender runs on debug level. standard production setting for the appenders is "info".
|
|
|
|
|
We use NLog for file logging and we created an email to help desk for any untrapped exceptions.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
I write log in my own log file..as simple as TXT file, I don't want tabulation, colors, style in my log.. I just need error line !
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
Same here. Small programs, use Mailsend to send to PHB.
User: Technical term used by developers. See Idiot.
|
|
|
|
|
File (using log4net), Elmah(?), Windows log, database, email, Application Insights...
I've seen them all (sometimes in the same application), no one really knows what to use.
And, of course, no one really knows what to log (at my previous employer we had to log EVERYTHING, which of course became unreadable...).
|
|
|
|
|
"And, of course, no one really knows what to log (at my previous employer we had to log EVERYTHING, which of course became unreadable...)."
Not always unreadable.
That's where log levels and a database log which can be filtered, wins over a plain file logging.
Key is also a structured way of writing your logs. We even have defined formatting rules for log lines. How and where variable values have to printed, what's in quotes and what not, what is in [brackets], how lists have to be logged, etc.
We even do code reviews over the log lines.
Nothing can crush your error investigation more than an unstructured pile of "lines" where everybody writes in the log what's in his mind in a specific moment.
The log is the most important thing in finding errors. This is nothing that "has to be done also", but more something that needs BIG attention and effort to keep it in structure. You win in the long run, when errors occur in production and you need to find their source...
If the structure of the log is clear you can also write crawlers that do a pattern matching and find unusual constellations, fully automated with a low rate of false positives.
You need a very performant db layer with background write that can handle high log density, but the debug level may spam. you only know that you needed a specific log line AFTER the error occurred, so you have a chance to trace back to the origin.
|
|
|
|
|
Let me clear that up.
EVERYTHING was logged in max. 10 MB flat text files in a multi-threaded environment (and keep a max. of 10 files before overwriting the first).
Good luck
I complained about it a couple of times and even left out logging altogether (except error logging, of course).
We never needed those logs and when we did we didn't because we didn't feel like going through all those log files
|
|
|
|