How do you feel about that lone error in your log

I usually try to fix any errors at all no matter the cost. Sometimes however it doesn't effect my gameplay at all and there's really no need to fix it. Like the one I have right now has to deal with positioning my characters on the level being loaded. It gives an error, yet positions my character anyways. I'm just wondering how many times you've come across something like this and decided to just leave it? Like the saying goes "If it isn't broken, don't fix it"

 

I never leave it. If I ship with an error it's just going to bite me in the ass when something DOES go wrong.

 

The only exception I have is Unity warning me that I might not be doing what I want to do yet really what happened was I just wrote my own code that would have done what their suggested function does

I mean sure, it'd get rid of the warning and maybe make it 2 ns faster, but I really don't want to go back into that UI code, it works

 

That's a warning, not an error, and it's not logged in a build. It's important to distinguish between warnings and errors. If the OP actually means errors, then no, it's never OK to leave one in a build, even if you think it's not having an effect.

--Eric

 

Sorry, my bad, I understand its a warning, I was just thinking back to that other conversation we had a recently here about whether or not to just hide warnings, meant it in the same gist

For errors yeah you shouldn't be having them

 

Never leave errors. I know people who just leave errors and warnings dangling, none of them probably mean anything and the game works, but the console is just filled with crap.

First, logging is slow in Unity. I think it has to do with the stacktrace and stuff it has to assemble for the logging, but it'll help your framerate in the editor if you don't log unless you need to.

Second, it's a lot of noise. What if there is an error that does matter and it's lost in the noise? You'll never see it because who, in the middle of everything while working on your game, stops to read the console if you're normally ignoring it?

No, I insist on a clear console. No compiler warnings (looking at you, random things from the asset store), no errors or logs during gameplay, nothing. If I Debug.Log something I comment it out or delete it when I'm done with it, or have a checkbox to disable it. If there are errors I investigate them and fix whatever is wrong even if it doesn't effect gameplay.

 

My motto is: Kill it before it breeds.

Then again, I've been told I'm a tad uptight. I can't even stand warnings in my projects.

 

Warnings are okay in small quantities if you know why they exist. Errors are never okay.

 

An error means project will fail to build. Some warnings can be ignored.

 

How could you leave it? Unity won't compile if you've got any errors, can't say I've ever tried to build with errors anyway..

 

There are various runtime errors, such null reference exceptions and so on.

--Eric

 

Any compile time errors are stuff that would NEVER work, those stop you from building. Anything that could work, but didn't the way you used it, will still compile

 

A lone error sounds really sad, it should have some friends.

 

Cool to see everyones unanimous view that it should be killed with fire lol. The thing is, I have no idea how or why its giving an error when it runs through perfectly fine. It's an error saying "Object Reference" yet it works perfectly. Its not a serious error, its just due to not getting a reference right away lol. No matter how many times I've tested it and ran it, it works but still gives an error like it still needs a reference.

That said, I probably should fix it somehow.

 

Yeah ... if the error is consistent and easy to replicate, it should be easy to find the source of the problem.

The real pain and nightmare are those "one time" sneaky errors. Don't know the source, can't seem to replicate. Especially if it got logged unnoticed, in a way you don't even know WHEN during testing it occurred.

You already know you're up to a big quest. It's scary, you may not return alive. But if you're truly the ultimate knight of the codez as you claim to be so smugly all the time, you never shy away from danger!!

 

And you can't isolate any part of it to find out whats wrong otherwise it'll give even more errors.

 

That's because errors in scripts don't stop your whole game, they just stop the current call to that script. That will often cause further issues that do stop your game, but just because this one isn't doesn't mean it's a good idea to ignore it.

It sounds like something is using a reference set up in another script before that script has been run for the first time. By the next frame the reference has been set so the error goes away. The error should at least tell you what script or component it is originating from, and you should be able to track it down from there.

Post a screenie of the error message (in its expanded form) if you need a hand.

 

Thank you the offer, but I actually fixed it It stopped when I switched from OnLevelLoaded to SceneManager.sceneLoaded. Don't know why it fixed it, but it did.

 

If you don't know why it went away you also don't know that it's fixed. For instance, it could be execution order dependent, and you don't necessarily know what might change your execution order.

 

Naah... a game without errors is like a night without stars...

 

May I take you up on that too? I get these errors (each one twice with exactly the same message), just from opening the project and I can't figure it out what it is, except it says AssetStoreClient. But I don't have the assetstore tab active on launch and when I click it the assetstore works and no further error occurs.




When I hit play I get another one:




I would assume these are not-my-fault™ and are Unity bugs, but I'm not sure.

 

It sure looks that way, given that they're Asset Store related and don't seem to come from any code you've written.

I get stuff like that from time to time, though not usually as repeatably as you describe.

Sure, but what I really meant was that if you're making a post about an error, there's not a lot anyone can offer if they can't look at the error.

 

Lol, I didn't know one could just ignore errors. I always stall my progress just to correct any errors that occur. Granted the kinds of errors I get are usually game breaking but literally never thought of just leaving them.

 

In the early development of Pond Wars an object going out of the game boundaries would mess up the bouyancy physics, causing the console to be spammed with all sorts of errors. I solved it with somethings like this code:

Code (CSharp):

1. try {
2.     GetMyBouancy();
3. } catch {
4.     Destroy(gameObject);
5. }

Months later I made changes within an essentially unrelated algorithm that generated the water. I made a mistake somewhere in the code. It took me hours to track down why changing the water generation code caused objects in my game to randomly disappear, all with no hints from the console.

Moral of the story: Always deal with your errors properly. Poorly thought out error suppression will always come back to bite you.

 

Properly and loudly. If something goes wrong in my code I don't want it to be shy, I want it to scream in my face so I can't possibly fail to notice it.

 

Try/Catch is really dangerous also. I really think exceptions should almost never be actively used in games, I would even prefer if really fundamental exceptions like null pointer and index out of bounds didn't exist and instead returned default values. Although obviously that's pretty extreme.

 

Meh, I disagree to any extent. Any time I throw an exception in my code it's because if that exception wasn't thrown and I sent back null or default the rest of the program wouldn't be able to function, it wouldn't make sense with the default value, so I use the exception as an explicit way to show that. Also, during constructors, can't think of any other option there

 

There are always options and always ways to avoid throwing exceptions, at least, when dealing with code you wrote.

Dictionary.TryGetValue is a good example, compared to Dictionary[x] which throws on fail. You can also do stuff like return out error conditions or the like.

I understand why nulls exist, but sometimes I really question if they were a good idea.

 

Nulls are fine, how else would you explicitly express that something hasn't been assigned a value yet? But I'd prefer if null behaved like in Objective-C, where it's fine as a parameter or even sending messages to null (iirc - it's been years).

 

I don't stand for a single warning, let alone an error. Most of my methods will throw a custom exception if handed garbage, so I can track the rarer events too.

 

A generic catch that grabs everything is a bad idea. But there is nothing wrong with throwing and catchin specific errors.

In my case I should have detected the out of bounds condition and thrown a specific OutOfWorldBoundsException. Then I should have caught that specific error, cleaned up, and logged a specific message detailing what happened to Te console.

A default value would have been a very bad idea. The method returned a float, and in the context of the calling method, any float would be valid. So I would have to remember every time I called the method to check for the default value.

Sometimes default values make sense. But most of the time it's a bad idea. If a default value is valid, the rest of the program can continue assuming it's real.

 

Code (CSharp):

1. if( !TryGetMyBoyancy() ){
2.   // log, propagate failure notice if needed
3. }

If GetMyBoyancy can throw, then you need to wrap any potential call in try/catch anyway, by writing the failure condition into the method name+signature you both bring attention to the fact that the call has failure conditions and avoid having to wrap everything in try/catch to avoid blowing up the stack.

I will admit, this is a strong personal preference, and I am definitely in the minority on the subject.

* Obviously, when dealing with 3rd party code, it's a whole diff story.

 

Approaching my original problem, what exactly is the difference between OnLevelLoaded and SceneManager.sceneLoaded? It's what fixed my problem, but I have no idea why. Is it execution order or something else entirely?

 

Sounds like "shooting the messenger" to me. Exceptions aren't a bad thing. They are just a standardised way to tell us when something has gone wrong, and it is absolutely in our best interest to always know when something went wrong.

Most of the time when I use an exception it's to protect from errors that may arise outside of my/our domain of control. For example, if I'm saving to disk then there's all sorts of stuff I only get to cross my fingers and hope for good luck with. What if there's not enough space? What if the user has ejected the disk I was working with? What if it's a network drive that's disconnected? Incompatible file permissions? Some other process has locked the file? Default values are useless, and while they're lighter weight the old school enum typed results approach is, at the end of the day, just a simplified, less flexible version of an exception.

And then you would have to guess whether it's a legitimate default value or a default representing an error.

That said, in your particular case I don't think it really matters what you do in code to handle the results of an error. You need to either design so that errors can be corrected, or so that they can't/don't happen. Either way, if an error case creeps in then it's a critical bug that needs fixing ASAP, so it's more important to advertise it than it is to enter some state of "graceful degradation".

 

It has nothing to do with the messenger, it's because unrolling the stack is maybe the worst form of flow control imaginable. Anyway, that discussion is way beyond the scope of this thread. Apologies for even bringing it up.

At the end of the day, you want to expose problems as early and as clearly as possible.

 

From memory there is some discussion in this thread on the differences between the two methods.

https://forum.unity3d.com/threads/important-function-deprecated-what-is-the-new-alternative.424746/

 

I agree entirely, which is why it should only be used in "exceptional" circumstances.

 

I would assume it's because they are executed in different orders/different time so object states will be different.

https://docs.unity3d.com/Manual/ExecutionOrder.html