17
votes
Should we abandon the "if not null" pattern?
There are a few reasons this has fallen out of favor. Out parameters require mutability, because you have to create a variable in the calling code that the function mutates. Out parameters are better ...
10
votes
Should we abandon the "if not null" pattern?
The bool TryXXX() pattern is not designed to avoid nulls. A method could assign null to an out parameter so technically you would still have to check.
It's needed in locking situations, say where you ...
3
votes
Should we abandon the "if not null" pattern?
This has been around since the early days of .Net - e.g., TryParse(string). In that particular case, it was, among other things, a way for the dev to indicate that an exception shouldn't be thrown. ...
3
votes
best practice to recover or handle a request that is half completed or partially failed
Where a transaction is impossible you have to roll your own recovery.
This is impossible to do in the scope of a single request. But you can clean up after the fact if your audit log is good enough
...
2
votes
best practice to recover or handle a request that is half completed or partially failed
If this is a transaction you roll back the work done by the completed tasks and report that the transaction failed.
Sometimes separate tasks must be successfully completed together or not at all. That'...
Only top scored, non community-wiki answers of a minimum length are eligible
Related Tags
coding-style × 1007coding-standards × 142
java × 98
c++ × 96
code-quality × 87
programming-practices × 75
c# × 72
python × 72
clean-code × 65
design × 50
c × 49
javascript × 44
naming × 43
object-oriented × 42
readability × 36
php × 27
language-agnostic × 24
design-patterns × 23
comments × 21
refactoring × 18
conditions × 18
architecture × 17
code-reviews × 17
variables × 16
code-formatting × 16