Hey so Java question... I know this ain't stackOverflow but...

I have a method and there's an assumption that the input can never be null.

Should I leave assert ... In the source code for production? Or raise an exception with an if? Or just leave a comment?

@dfox I can't change the rant type on edit? I usually always Auto select Rant... But just realized this isn't a rant.

I am a newbie to Java, but I do always have a null-check. Never trust anyone on input.

Well do you catch at one place all the exceptions that might happen so you can notify the user? If so, you might throw the exception with some meeningful message.

I would say it depends a bit on the input. When it's a library you are writing and something passed is null, throw an exception and give a good hint in the constructor of the Exception :D
Otherwise you should catch that with an if-clause and tell the user to try again or something like that. An analogy is for instance the input of an username. Probably they will leave it blank, so you check that to tell them that username can't be blank 😊

@FrodoSwaggins

I guess my issue is not really the testing but reuseability. If another dev/future me decides to reuse the method or "copies and paste" I kinda of want to say "You understand by using this code you never pass it ...."

@billgates I think it wouldn't hurt to throw an exception with a clear message and it'll always be clear how to use the method.

Actually if you think about it, if there is any chance that method will be used in any other context than your current invocation is way more secure and easy to read to have an if with null checking and throw an ArgumentNullException anothrr option would be to create or use an annotation @NotNull, i remember seeing it somewhere but i dont recall perfectly, But no, i would never assert, because of OCP, if something happens in your execution context the you would have to remove the assertion.

Hope it is useful

It's usually a good practice to always take null values into consideration. You never know what the user will input hence your code should always consider all the test cases even the null-checks. In fact, null-check is usually the first thing I include in my code. Throw an exception/ use if to check for null and return; to display a message stating that null values aren't allowed.

Annotate with @NonNull ? Or if you dont use lombok, id throw an exception, better safe than sorry.

Edit: https://projectlombok.org/features/...

Edit2 except im out of 5 minutes: generally its a good idea to do as much error handling in methods as possible, so your 'main code' remains readable. For example even if i dont use null as a parameter i can upcast some object to the input that doesnt work, or downcast a plain Object. These are stupid examples because whyd i do that, but your code is eventually going to be used by idiots so.

A little bit late, but why not use the optional api? The code can be cleaner and more functional.

@BillGates

@jpichardo not sure what that is, Java?

I guess this question is more just coding style maybe. How to put in this check/assumption

@billgates yeah java 8 basically it allows something simillar to null coalescence, like the elvis on c#, but on esteroids because it takes funcional operations. Thats why it is easier to extend, not sure if it is what you need but it might help to know especially when there are lots of null checks there is a so question that explains it let me check

avtulaly just read https://ted.com/talks/...

Apparently theres some new in code thingy... Architecture Design Records.... https://github.com/npryce/adr-tools not really sure but was in this thing i just read

https://assets.thoughtworks.com/ass...