Last call to make your voice heard! Our 2022 Developer Survey closes in less than a week. Take survey.
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 ...
user avatar
  • 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 ...
user avatar
  • 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. ...
user avatar
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 ...
user avatar
  • 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'...
user avatar

Only top scored, non community-wiki answers of a minimum length are eligible