That’s what stacktraces are for…
That’s true, but some things don’t throw exceptions and logging helps recognize the source. Stacktraces help track down a particular instance of a called method, whereas logs can still help find the originating class when it’s not necessary to know when or where it was called.
No. You confuse the purpose of logging with the purpose of writing a text to the console (via System.out.println() for example). Bukkit’s handling of loggers - giving one to each plugin and advise developers to use this logger for the whole plugin - has been a flawed usage of Java’s logging capabilities. The de facto standard is to use one logger per class.
Besides, since Minecraft (and therefore Forge and Spout) use log4j2 which can be easily configured by each server-admin if the class-name should not be included in the logged message. So essentially this thread is completely unnecessary since the logger can be configured to look just like every individual server-admin wants.
I’ve seen all kinds of logging and I appreciate Bukkit’s implementation. I wouldn’t want to have a logger per class in my plugin. I would rather have a logger for my whole plugin and just read from a stacktrace when an error arises.
Just my personal opinion. I’m not saying it’s the best, most informative way of doing things, but it’s my favorite way.
@OffLuffy I’m not sure what you mean… I’ve always needed to track down the exact instance of an issue when it comes up. I would rather it do that than only give me the class that the error is in and I have to go fishing for the issue… Which would be especially bad in a bigger class that has hundreds or thousands of lines of code.
Not every problem can be solved with a stacktrace. You don’t always have an exception or want to generate a stacktrace(because that is costly) and log it. Sometimes problems are not errors and exceptions, but wrong logic, wrong filtering, wrong configuration, etc. Those problems can be easily pinpointed by logs. Added to that, logs tend not to be very useful during development, but extremely valuable after release.
By having a logger per class, it is completely clear from the log where that log line originated. Without the classname, you will have to do a string find in files which might end up with 10s to 100s of results. Also, having a logger per class also means you don’t need to include that specific information in the log line.
e.g. forge core mods allow you to define class transformers which can change classes while they are loaded. It is quite common to have more than one if they solve specific problems. With a logger per class I can just have logger.fine("Transformed " + name); in both class transformers without having to add specific data about which transformer it is or even to worry that I will have trouble determining which log line originated from where.
And, added to that, forge logs are based on log4j2 meaning that you can easily configure it yourself if you want. Do you not classnames? just change the pattern in the config so that the classname is not logged.
2 Likes
@Zerot pretty much got what I meant. Stack traces are generally helpful, but not always. Like if I had something like this
public static int getFive() {
int five = 4;
logger.fine("getFive() = " + five); // getFive() = 4
return five;
}
And that’s a horribly dumb and useless method, but fact is, it’s valid and won’t throw an exception, so it won’t generate a stack trace, but the logic is clearly flawed, be it a typo or whatever. The same applies to very complex logic where you may want to log a variable’s progress after different steps in the logic so you can pinpoint what part of the logic is flawed. If you put a logger that printed out the result of the method call, then it could tell you where the method is (or where the method is called from), but the instance of the method isn’t helpful or the entire stacktrace.
Well, it won’t compile 
since you’re making a statement after a return.
But you’re point is valid.
Fixed XP I realized that earlier, then got distracted putting something else there instead of fixing it. Thanks
1 Like
It doesn’t need a config.yml, Honestly I hope they NEVER do
How find such error: ctrl+f hardcoded string
If you have a configuration error and want to log it without a stack trace, shouldn’t the description of “Something went wrong when parsing the config. Here’s what it had” be enough to know that the error is in the configuration class where you parse the config?
Bit aside the point, but please don’t ping me on a necro post -.- Had long since unsubscribed from this thread.
Practicing a bit of Necromancy here, if anyone is still keen on this subject:
Logging is a Hot Topic on SpongeDocs right now. The Logging pages need some work. It’s issue #15, and there’s a matching a PR that needs overhaul at Explained logger section. by Pepejson · Pull Request #17 · SpongePowered/SpongeDocs · GitHub
If anyone else has some sensible input on this, now would be a good time.