Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Assert!!

Discussion in 'Wish List' started by Robota, Mar 25, 2013.

  1. Robota

    Robota

    Joined:
    Feb 7, 2012
    Posts:
    82
    I just want an assert like in C/C++.

    Or add a conditional boolean to the Log function:
    Debug.Log(condition, "my text");

    So simple and so useful...
     
  2. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Are you serious?

    Code (csharp):
    1. public class MyDebug {
    2.     public static void Assert (bool a_Condition, string a_Message) {
    3.         if (!a_Condition) {
    4.             Debug.LogError (a_Message);
    5.         }
    6.     }
    7. }
     
  3. Robota

    Robota

    Joined:
    Feb 7, 2012
    Posts:
    82
    Of course I' am serious.
    I wrote this kind of code already and use it.

    In a big project this code is not handy because if you double click on the displayed error you jump to your assert function.
    Then you have to search with the error message in your files, not great.
     
  4. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Right, that's true. On the other hand, I don't see a problem in writing

    Code (csharp):
    1. if (!condition) {
    2.     Debug.LogError (message);
    3. }
    instead of

    Code (csharp):
    1. Debug.Assert (condition, message);
    Both variants are readable and intuitively understandable. It doesn't save you days of work over a year. It is a small abbreviation that is not really needed in my opinion.
    Certainly I see your point. It's your opinion and that's okay. I just wanted to make my first post clearer, as it was not my intention to be disrespectful.
     
  5. Robota

    Robota

    Joined:
    Feb 7, 2012
    Posts:
    82
    Code (csharp):
    1. if (!condition) {
    2.     Debug.LogError (message);
    3. }
    Yes it is the best solution for now.

    There is no problem, thank you for your interest in my post.
     
  6. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Make a DLL for the assert function, then double-clicking on the error will go to your code, not the assert function.

    --Eric
     
  7. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Creating a dll for 3 lines of code :) ! It solves the problem and it's a good idea, but it feels weird and funny that it takes longer to click all the button for the compilation than writing the code.
     
  8. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Well, you could think of some more functions to add, so it would be more than 3 lines. ;)

    --Eric
     
  9. mweldon

    mweldon

    Joined:
    Apr 19, 2010
    Posts:
    109
    Am I missing something? What's wrong with doing something like this:

    Code (csharp):
    1.  
    2. if ( !condition )
    3.   throw new System.InvalidOperationException( message );
    4.  
     
  10. Robota

    Robota

    Joined:
    Feb 7, 2012
    Posts:
    82
    Not simple enough ! ;)
     
  11. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,660
    Throwing an exception changes runtime behaviour. An assertion isn't supposed to disrupt program flow any more than potentially pausing the app (breakpoint-style) to display a message.
     
  12. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    For me it doesn't make a difference if I see an error message in the console or I see an error message because an exception was thrown. Something went wrong, which is under all conditions a bug and everything from that point on is not anymore reliable. But you are right that it can make a difference for the debugging.
     
  13. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Ideally the console would allow jumps to code or the object the script was on.
     
  14. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,660
    If it's a situation where you really can't continue, then an exception makes sense, but in a team environment you often have to find a way to just turn the feature off and let people continue working - for example, if there's no navmesh baked for a scene, you might want to assert in order to warn the user, but then turn the AI off and let them just look at the level artwork (because they're artists and need to check out this new object they just put into the scene etc).

    Note that I'm thinking of assertions that (a) pop up a dialogue box and actually halt the program until the user hits either "ignore," "break to debugger" or "terminate", and (b) are automatically compiled out in release builds.
     
  15. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    I see this differently. In a team environment the whole master branch has to be stable. Meaning no single error message. You never know when an error can have unexpected side effects. From my point of view, anyone who makes a commit is responsible that it breaks nothing. Practically there will be commits which introduce bugs. But finding them in a stable environment is a lot simpler and faster.
     
  16. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,660
    I'm not sure that's suitable to all workflows - there's often not time to make sure everything is 'stable' before giving it to the rest of the team, particularly when working in an exploratory/prototyping style. But anyway, what about pre-commit? If I'm adding a new object to the game and want to check how it looks before I set up all the other aspects of it, I should be able to do that, but it's reasonable that it complain about the missing parts.
     
  17. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    If you make an experiment, you can create a branch for it. So let's say an artist updates the ground of a level, meaning the NavMesh is not anymore valid or doesn't exist at all. For a first test, no one cares about it. But as soon as it is commited to the master brunch, there should be no warnings at all, even if there are placeholders for stuff like the NavMesh. Certainly, it should always be obvious to everyone that it is just a placeholder.
    Especially in prototyping it is important to have a solid basis. As a coder there is nothing worse than coding new functionality based on crappy code or broken scenes. If something doesn't work you rely on, it is necessary to create workarounds. Workarounds are charming! You can produce fast results, which is exactly what you need in prototyping and everyone is happy. Later on it may become necessary to fix the crappy code or the broken scene. This may break the workaround and lots of other code, because there is a dependency from this to that, oh and there is another workaround and I don't know what this code exactly does but it also seems to be related somehow... Now you have a hell lot of work to get it working and this takes a lot more time to get rid of the problems than fixing the crappy code at the very beginning. This is not in the interest of the project! That's the reason why I strongly believe that spending a little more time (sometimes only minutes or maybe one hour) to bring the project from broken or crappy to stable and sufficiently maintainable. There are times, especially in prototyping environments where you need to have the balls to say: I don't continue until this issue is resolved.
    It is mostly more efficient to resolve issues when they are discovered or invented :) . You have an idea about what happens, you understand the context. Later on you may just see an unwanted side effect of it and then an extensive bug isolation needs to take place. Or if a workaround was used, it is very tricky to understand the context again. With that kind of situations you just waste too much time. And from my point of view, this could very often be avoided.

    As a side note: We are offtopic :) .
     
  18. lee_

    lee_

    Joined:
    Nov 25, 2012
    Posts:
    2
    I think a balance needs to be struck. When you make a nontrivial code change, you never know when that can have unexpected side effects. This does not mean you block your entire dev team from working with the latest build until it has gone through rigorous testing. An assert is just a manifestation of a bug, conceptually no different from if a human tester discovered a bug, or if an error was logged. If your tester found a bug, indicating your master branch is unstable - do you prevent the team from further development on that branch in case there are unexpected side effects? You might, but it should be handled on a case by case basis.

    In striking a balance between productivity and stability, I'm not sure blocking others from progressing *just in case* there is some unexpected behavior introduced is warranted. Worse yet, it may discourage people from liberally adding asserts where they might be warranted, because they know the condition is non-fatal, and feel its overkill to abort the program if it detects this unexpected (but otherwise benign) condition, but are given no alternatives. Now the problem may go completely undetected.

    While I rarely use asserts, a common use case is validating an input vector is normalized in performance critical code. Your pipeline should ensure data is provided in the correct format, but should the pipeline break (someone adds in new tools without testing them), you will never know unless there are some asserts in there to pick it up. Sometimes the non-normalisation is benign (say, a plane class that is only performing sidedness checks, but checks for normalization in the constructor), other times it can be a problem (distance checks that cause problems downstream).
     
  19. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    @lee_, if complex code is added, it would be a wonder if it works correctly under all circumstances. If no breaking changes are known, there is usually no problem to add it to the master branch.
    There was the example of the missing NavMesh, which means you hit play and the console has at least one error message if not many. When I check the master branch, there should be no single error message when I hit play. Stability is always relative, but in my opinion something that produces an error just because you hit play should never be in the master branch.