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 ...
- 13k
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 ...
- 64.1k
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. ...
- 6,657
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
...
- 64.1k
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'...
- 88.4k
Only top scored, non community-wiki answers of a minimum length are eligible