If C idioms work better in your project, just go for C. You get other advantages from that, like faster compile times and being independent from C++ stdlib, which can be messy at times (not even speaking about Boost). You don't have to stay with C++ just because somebody else (or even you) thinks that it's generally a better language.
Similarly while exceptions are part of the Java idioms, it does after all have checked exceptions even, it's incredibly common to not use that idiom on constructors, where it's weird. Just because a thing is an idiom in some cases doesn't mean it's the expected idiom in ALL cases.
And if an idiom is dumb it doesn't mean you should just do it to follow along with the dumb, nor should you go to a language where you're forced to be less safe & less clear just because "but mah idioms". Be the change you want to see.
1: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070... has the survey data (along with a language proposal to make return-value exceptions a proper C++ feature)
Similarly I'd probably substitute the optional with a variant that has the actual error code. Go nuts with whatever you want here.
Let's make error code optional, too.
typedef struct
{
int err;
int value;
} rtn_t;
rtn_t rtn = foo();
if(rtn.err < 0)
printf( "err=%i", rtn.err);
else
printf( "value = %i\n", rtn.value);A seasoned dev that thinks errno and longjump are good idea's should have retired 25 years ago.
But only one of them would make sense at a given moment, so why waste memory?
By comparison some something like https://github.com/oktal/result will tell you if it's a success or error without any magic error codes that actually mean success.
You could do this with a type bit + union in C, it's just more painful without templates
In c it'll be either in a register or on the stack.
Then again, many C++ younger devs don't even know what Booch method might be all about.
Just because they may be overused in Java doesn't mean people shouldn't use them at all in other languages.
And you can do things like enforce that the return value is used by checking in the destructor if the return value was unwrapped.
Similarly for constructors if you have an object that can fail construction instead of doing what the author suggested of
You could instead do something better like: This is a well-established pattern in languages like Java, for example, to do exactly what the author wants - a constructor that can fail without forcing callers to just know they need to try/catch.