Warnings are design errors.
https://dev.to/sebach1/...

I think is better to paste the post here, but it doesn't allow MD :(

Wanna hear your opinions.

Fuck warnings.

Useless warnings suck, like the one with Logstash in the article. The system should be smart enough to figure out that the warning is unwarranted. If it can't, that's because it was misdesigned.

However, e.g. for code, compilation with lots of warning appearing smells bad code. It's valid syntax, that's why no error, but it probably won't do what the dev had intended. When using -Wall and -Wextra, no warning should appear.

Then we have devices. Any time the device is approaching a critical state AND cannot do anything against that BUT the user can and usually should, a warning is required.

You don't want your laptop or mobile to suddenly switch off without any prior warning that charging is needed, do you?

@Fast-Nop Oh yes, of course. I think warnings are design errors but in logging.

There are desired for the real world in general at the hour of having uncertainty. I mean, a semaphore is better with a yellow light than without it. Binary states aren't always possible (or desired, too).

The problem is logging warnings.

Using your example of code compilation, I think that if anything can be done in such multipĺe ways that you can detect the dev coded an antipattern that "can or cannot" work, it needs to be an error.

Or you shouldn't allowed the anti-pattern to be made in the first place.

@sebach1 So for the programming, the idea is that warnings instead of errors are usually the result of having violated the principle of the least surprise when designing the language? Because the warning then is "it will work, but probably not like you expect".

Makes sense. One thing that I noticed is that many aspects of usability go totally out of the window once stuff is "for development". Somehow, devs are expected to put up with all sorts of crap.

This brought to my mind therac-25

Well yeah fuck warnings. There are times though in which they are unavoidable, like when they are being thrown erroneously and you have to wait on the maintainer to merge a fix

I guess it depends on your enviroment. Usually seeing warning in PHP means that you should look into it and 99,9999% there is an errornous situation going on. There are also notice's here, but they usually mean something not good is going on too.

(like using uninitialized variable. Maybe you had typo in it, right?)

I think it's just how warnings were used, warnings themselves are tools, and it's up to coder if tool will be used properly, meaningfully, or not.

There was example of module not loaded (would be 2nd time) - at this point in PHP you usually throw that stuff into debug/verbouse logs, unless this sounds like missconfiguration issue that could lead to problems.

Hmm.. I'm not saying that warnings need to be ignored or aren't useful.
What I want to explain is that, if the design was better, the warning is not needed anymore.

So removing a warning implies a deeper change in the software, and when time is an important variable you want to avoid deep changes with shortcuts, like warnings.

@sebach1

Not exacly. Warning could for example be thrown when you use fallback becouse some dependancy (like in PHP, extension) is not met. It's not design issue.

It can be design problem, but I find myself quite often add warnings to my code, but most of them never triggered, and I don't think that defensive coding is design problem, but more of design decision.

E:

Of course, missused warnings are well.. missused.

@DubbaThony Hmm but if a dependency isn't met, that's an error. Or I'm losing something...

@sebach1

Can be. But dosen't have to be.

You can have in PHP block like that (note that's the simplest example I could find quickly):

if(!function_exists("http_redirect")){
$logger->warn("php http extension not loaded! Please install pecl_http extension.");
function http_redirect(string $whereTo): void {
header("Location: ".$whereTo);
}
}

E: imagine indents ;-;
E2:
And probably you want that extension. Becouse it probably does something more than this, and is written in actual C, thus it will execute slightly faster. Fallback is well, nicer than crash, but warn-worthy.

@DubbaThony I see...
Thing A can be done in such a B or C way. C is faster than B, but both are valid.

For me it admits two positions:

1. You think that doing a thing in a slower way is bad, so you can log an ERR.

2. You think that doing a thing in a slower way isn't bad, because maybe faster doesn't mean better (because, idk, very complex algo?) so you send an INFO message that the dev can do it in another, maybe better, way.

A warning is a possible error. This case isn't a possible error for me. A "hint" is for me an INFO-level log, not a WARN.

@sebach1

Using fallback dosen't mean it's OK to leave it that way, and is worth warn or at least notice, but isn't worthy error, becouse error means crash, RIP.

Another way when you can have something even weaker than warn, namely notice (lowest native error level in PHP except deprecated) often indicates someting going wrong (or typo).

My point is, it really depends on enviroment. For example, honestly, I never seen java app that dosent produce ton of ignorable warnings, while in PHP warn should worry you unless you know that warn and you know it will not hurt you. Error on second hand in PHP means "oh shit" scenario, like in cpp you have segfault error (that kind of severity)

@DubbaThony Well, environments are a complex thing.

I've felt that if the env is forcing you to use a specific type of warning to follow its specific pipeline you just going to 'round down' your design.

So if the lang is lacking design in a feature, you'll can't perform better on it if working with it.

At the same time, it's a bit about perspectives to think that a thing can be done in multiple correct ways.

In my opinion, an ideal design pattern is one in which you can achieve your objective in the best and unique way.