Runtime optional interface

[SasQ]

Howdy.

Is it possible to write a class with some of its
public interface being optional and dependant of
the runtime circumstances?

In the "Object oriented design heuristics" book,
chaoter 5.18 Arthur J. Riel has mentioned the same
problem, but he hadn't shown any good solution.
He wrote that there are two solutions:

1. Putting the optional interface in an inherited class.
2. Making the optional obiect contained by reference.

Solution 2 is not convenient for me, because the only
way to return the obiect or nothing is returning the
pointer. So if the optional functionality isn't available,
I'll have to return a null pointer, which may bring to
program crash if the user won't check that pointer but
use it immediately to access methods of the optional
interface. Secondly, returning a pointer to that
optional interface could be an opportunity for an
error if the user would delete it after use. It may
cause a crash if that interface is a part of the
containing object and is used by it.

The solution 1 isn't any better because it's more
static. At runtime I might create either the base class's
object, or the derived class's object, but still I have
to know which one is constructed to use that optional
functionality.

I'm thinking about some way to achieve this better,
because in my program I have some functionality of a class,
which is optional and I can know if it's available only
by checking that at runtime. But I think that allowing
the user to call this optional interface's methods, and then
rewarding the user with an error, isn't a good solution [though
it's commonly used practice], because the object know well that
the optional interface isn't available BEFORE the user might
call it. I would to offer that optional functionality for
the user only in the case that functionality is available,
and if not, I would like to not allow him to call it.

Is there any good solution of that problem in C++?
Maybe some design pattern or sth like that?

 

[Victor Bazarov]

Is it possible to write a class with some of its
public interface being optional and dependant of
the runtime circumstances?

No. Class interface is a compile-time thing and it cannot
be optional. Class _functionality_ (behaviour) can change
depending on some conditions, and for that a simple 'if'
statement is often enough:

class TellSeason {
public:
void doTell() {
// get current date
if (month == January
|| month == February
|| month == December)
std::cout << "winter";
else
std::cout << "not winter";
}
};

In the "Object oriented design heuristics" book,
chaoter 5.18 Arthur J. Riel has mentioned the same
problem, but he hadn't shown any good solution.

Maybe because there isn't any...

He wrote that there are two solutions:

1. Putting the optional interface in an inherited class.

<shrug> ...and what? If a pointer/reference to the base
class is going to be used, the interface has to still
be _declared_ in the base. It's not optional.

2. Making the optional obiect contained by reference.

Solution 2 is not convenient for me, because the only
way to return the obiect or nothing is returning the
pointer. So if the optional functionality isn't available,
I'll have to return a null pointer, which may bring to
program crash if the user won't check that pointer but
use it immediately to access methods of the optional
interface.

To prevent that you need smarter users. And you need to
document your pointer-returning function, especially in
the respect that it returns NULL in case the optional
functionality is unavailable. If the users don't check
the pointer for being NULL, it's their problem, not yours.

Secondly, returning a pointer to that
optional interface could be an opportunity for an
error if the user would delete it after use.

Again, that is usually solved by proper documentation of
your functionality. If the user is not supposed to delete
the pointer, just say so in the documentation.

It may
cause a crash if that interface is a part of the
containing object and is used by it.

The solution 1 isn't any better because it's more
static. At runtime I might create either the base class's
object, or the derived class's object, but still I have
to know which one is constructed to use that optional
functionality.

I'm thinking about some way to achieve this better,
because in my program I have some functionality of a class,
which is optional and I can know if it's available only
by checking that at runtime. But I think that allowing
the user to call this optional interface's methods, and then
rewarding the user with an error, isn't a good solution [though
it's commonly used practice], because the object know well that
the optional interface isn't available BEFORE the user might
call it.

I am not sure what you mean here.

I would to offer that optional functionality for
the user only in the case that functionality is available,
and if not, I would like to not allow him to call it.

You're probably imagining things. C++ is statically typed
language, which means all types' interfaces are known at
compile-time.

Is there any good solution of that problem in C++?
Maybe some design pattern or sth like that?

Well, you mentioned polymorphism, that's a very good solution
for that. Why can't you go with polymorphism?

Perhaps you should explain from the "user"s point of view
what it means to have "optional" functionality. How does
the "user" take advantage of the "optionality" of the
interface?

V

 

[Joe Greer]

Sounds like you have some conflicting requirements. You don't want to
tell the user the interface isn't available (by returning a null
pointer), nor do you want to give him errors when he invokes methods on
the interface. The only way I can see to achieve that is to not make
the interface optional.

Now, a lot of the solution will depend upon what your design goals
actually are. Do you want the interface to always be there, but the
implementation loaded only if it's used? Do you want to deny
functionality unless they install some add-on?

My first thought would be a Interface * queryInterface() sort of
approach where you either get back a valid pointer to the interface or a
NULL. If you don't want to return a NULL, you could throw at this point
and make them deal with it in some other fashion. The nice thing here
is that if you just don't want the overhead of loading the
implementation if it isn't needed, you could have this method create the
instance that implements the interface at this point (much like some of
the singleton patterns).

C++ is a statically typed language. One of the effects of this is that
the user either uses the optional interface or he doesn't when his code
is compiled. If he doesn't, no problem. If he does, then he needs
access to the interface whether the interface is "available" or not.
Now, if the implementation is always available if he is going to use the
interface, then, again, there is no problem. The problem comes in when
the user doesn't know if he has the interface or not. In this scenareo
the user has to test for the presence of the interface in order to take
the correct code path. There are a lots of ways you can provide for him
to test this. You could provide a method bool hasInteface(), you can
let him query the interface and test if it exists (the Interface *
queryInterface() approach), you can have the interface methods fail if
they aren't available, or some variant of these. Personally I would be
really annoyed at a error from the interface methods. I would much
rather make my codepath choice up front.

A last approach is to make everything dynamic (such as they do with
things like browser addons). The problem with this approach is that the
user still has to deal with whether or not the interface is available
and he always has to invoke methods in some interpreted sort of fashion.

Good luck with your problem,
joe

 

[SasQ]

No. Class interface is a compile-time thing and it
cannot be optional. Class _functionality_ (behaviour) can
change depending on some conditions

OK, maybe the optional _functionality_ will be enough for me

and for that a simple 'if' statement is often enough

I think simple 'if' isn't enough this time.
But maybe I should think more about that ;J

<shrug> ...and what? If a pointer/reference to the base
class is going to be used, the interface has to still
be _declared_ in the base. It's not optional.

That's why the solution 1 doesn't convince me also.

To prevent that you need smarter users.

I believe they are But I believe also that they're
humans and can make mistakes [unconsciously].

And you need to document your pointer-returning function,
especially in the respect that it returns NULL in case
the optional functionality is unavailable.

I like the Eric Raymond's attitude that the code should be
the only documentation the user needs [in fact, he stated
that according to user interfaces, but the rule is valid
for the source code too].

I'm thinking about some way to achieve this better, because
in my program I have some functionality of a class, which is
optional and I can know if it's available only by checking
that at runtime. But I think that allowing the user to call
this optional interface's methods, and then rewarding the
user with an error, isn't a good solution [though it's
commonly used practice], because the object know well that
the optional interface isn't available BEFORE the user might
call it.

I am not sure what you mean here.

I mean the following is IMO stupid:

SomeClass someObject;
int error = someObject.doSomethingOptional();
if (error) ...;
else ...;

because someObject know BEFORE the user calls doSomethingOptional()
if the optional functionality is available or not. So, if it
knows that it's unavailable, but still allows the user to
call doSomethingOptional() well knowing it'll fail and,
after that, telling the user that HE has made an error,
for me it's very stupid Because it's not the user who
made an error, but the class's designer, who allowed the
user to call the optional functionality which sure will fail.

So I'm searching for a way to allow the user to call that
optional functionality only when it's really available
and disallow it totally if it's not available.

You're probably imagining things. C++ is statically
typed language, which means all types' interfaces are
known at compile-time.

Thanks for telling me that

Well, you mentioned polymorphism, that's a very good
solution for that. Why can't you go with polymorphism?

Because I don't know how to apply it in this particular
case. It's rather a design problem.

Perhaps you should explain from the "user"s point of
view what it means to have "optional" functionality.
How does the "user" take advantage of the "optionality"
of the interface?

I'm designing a class being an abstraction of a graphical
screen for a game. The optional functionality is the
window manager [yes, on systems other than Windows it's
possible to play the game in a system without WM available].
If the WM is available, the game screen works in a window
and has additional functionality available for the user,
like toggling between fullscreen and windowed mode, changing
the window's position and size, etc. I don't know at compile
time if the game will be launched with WM available or not.

First idea was to put the toggleFullscreen() and setWindowSize()
in the Screen class, but quickly I went to the idea that those
messages are not always valid for the Screen and it can't
do anything sensible if the WM isn't available. They simply
doesn't make any sense in the class if WM isn't available!
The user cannot be rewarded by an error, or those functions
simply and silently doing nothing ;P I'm looking for a way
to make it available only if the WM is available also.

Second idea was to put them all in a separate class
WindowManager, so the user could use it only if the
WM is available. But still I don't know how to give
the object of this class to the user only if the WM
is available, without using error-prone pointers.
WindowManager class is some kind bonded with the Screen
class, because some Screen methods should use it when
it's available [e.g. switching graphics modes is only
available on fullscreen. If there is WM available and
the game works in a window, and the user wants to change
the graphics mode, the Screen should toggle to fullscreen
where it'll be possible to change graphics modes. If
there isn't WM in the system, the game can work only
on full screen, so there isn't any problem then ;J ].

I think it cannot be done with polymorphism, because
if the WM is available, the user should have some way
to get know about it, and then he should have the
window manipulation functionality available.

 

[Victor Bazarov]

[..]
I mean the following is IMO stupid:

SomeClass someObject;
int error = someObject.doSomethingOptional();
if (error) ...;
else ...;

because someObject know BEFORE the user calls doSomethingOptional()
if the optional functionality is available or not. So, if it
knows that it's unavailable, but still allows the user to
call doSomethingOptional() well knowing it'll fail and,
after that, telling the user that HE has made an error,
for me it's very stupid Because it's not the user who
made an error, but the class's designer, who allowed the
user to call the optional functionality which sure will fail.

OK, take it one step at a time. What do you call "a call", and
how can it be "disallowed"?

SomeClass &someObject = getObjectFromSomewhere();
if (someObject.hasOptionalInterface()) {
int error = someObject.doSomethingOptional();
}
else {
std::cerr << "there is no optional interface\n";
}

Is that what you're envisioning? <shrug> This still _requires_
the member function 'doSomethingOptional' to be _defined_ although
it is not going to be called provided that 'hasOptionalInterface'
is reliable.

So, 'doSomethingOptional' can be just a virtual function that
does NOTHING in 'SomeClass' (or even declared pure), but should
it actually be an instance of some derived class, it will be
called and it will do something. That's polymorphism in action.

So I'm searching for a way to allow the user to call that
optional functionality only when it's really available
and disallow it totally if it's not available.

class SomeClass { // will have some classes derived from it
public:
virtual ~SomeClass() {}
virtual bool hasOptionalInterface() const { return false; }
virtual int doSomethingOptional() = 0;
};

Now, derive the real class from it, provide (potentially empty)
implementation of 'doSomethingOptional' (if you want to be able
to create an instance of that class), and only if it's truly
capable of that "optional" stuff, override 'hasOptionalInterface'
and return 'true'.

[..]

Well, you mentioned polymorphism, that's a very good
solution for that. Why can't you go with polymorphism?

Because I don't know how to apply it in this particular
case. It's rather a design problem.

Yes. And you're probably approaching your design from the wrong
end. You need to become your user. Define the interface you're
going to be calling. Define the ways your class[es] is/are going
to be used. Don't start with "how do I implement something I do
not yet know".

Perhaps you should explain from the "user"s point of
view what it means to have "optional" functionality.
How does the "user" take advantage of the "optionality"
of the interface?

I'm designing a class being an abstraction of a graphical
screen for a game. The optional functionality is the
window manager [yes, on systems other than Windows it's
possible to play the game in a system without WM available].
If the WM is available, [..]

I think it cannot be done with polymorphism, because
if the WM is available, the user should have some way
to get know about it, and then he should have the
window manipulation functionality available.

*Everything* can be done with polymorphism.

V

 

[Maarten Kronenburg]

In my opinion the interface itself cannot be changing at runtime (because
what interface would a client then expect, that makes no sense), but the
implementation of an identical interface can change at runtime, and that is
in C++ the virtual functions (also called runtime or dynamic polymorphism),
see for example:
http://www.parashift.com/c++-faq-lite/virtual-functions.html
Also a design I made may be useful for you, that is N2143 on:
http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-01
Regards, Maarten.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Sounds like you have some conflicting requirements. You don't want to
tell the user the interface isn't available (by returning a null
pointer), nor do you want to give him errors when he invokes methods on
the interface. The only way I can see to achieve that is to not make
the interface optional.

[snip the rest]

Please quote the text you are replying to, not everyone have the same
newsreader as you do and have the ability to easily view the message you
replied to. Also keeping it in the same message makes it easier if one
wants to check something the OP wrote.

For more information about posing see section 5 of the FAQ:
http://www.parashift.com/c++-faq-lite/how-to-post.html

 

[=?ISO-8859-2?Q?Erik_Wikstr=F6m?=]

No. Class interface is a compile-time thing and it
cannot be optional. Class _functionality_ (behaviour) can
change depending on some conditions

OK, maybe the optional _functionality_ will be enough for me

and for that a simple 'if' statement is often enough

I think simple 'if' isn't enough this time.
But maybe I should think more about that ;J

<shrug> ...and what? If a pointer/reference to the base
class is going to be used, the interface has to still
be _declared_ in the base. It's not optional.

That's why the solution 1 doesn't convince me also.

To prevent that you need smarter users.

I believe they are But I believe also that they're
humans and can make mistakes [unconsciously].

And you need to document your pointer-returning function,
especially in the respect that it returns NULL in case
the optional functionality is unavailable.

I like the Eric Raymond's attitude that the code should be
the only documentation the user needs [in fact, he stated
that according to user interfaces, but the rule is valid
for the source code too].

I'm thinking about some way to achieve this better, because
in my program I have some functionality of a class, which is
optional and I can know if it's available only by checking
that at runtime. But I think that allowing the user to call
this optional interface's methods, and then rewarding the
user with an error, isn't a good solution [though it's
commonly used practice], because the object know well that
the optional interface isn't available BEFORE the user might
call it.

I am not sure what you mean here.

I mean the following is IMO stupid:

SomeClass someObject;
int error = someObject.doSomethingOptional();
if (error) ...;
else ...;

because someObject know BEFORE the user calls doSomethingOptional()
if the optional functionality is available or not. So, if it
knows that it's unavailable, but still allows the user to
call doSomethingOptional() well knowing it'll fail and,
after that, telling the user that HE has made an error,
for me it's very stupid Because it's not the user who
made an error, but the class's designer, who allowed the
user to call the optional functionality which sure will fail.

So I'm searching for a way to allow the user to call that
optional functionality only when it's really available
and disallow it totally if it's not available.

Perhaps dynamic_cast will do what you want:

#include <iostream>

struct B {
virtual void foo() { std::cout << "B::foo()\n"; }
};

struct D : public B {
void bar(){ std::cout << "D::bar()\n"; }
void foo() { std::cout << "D::foo()\n"; }
};

int main()
{
B* obj = new D();
obj->foo();
//obj->bar(); // Error
dynamic_cast<D*>(obj)->bar(); // Works
}

Notice that B has to be a polymorphic type (have a virtual function).

 

[Victor Bazarov]

No. Class interface is a compile-time thing and it
cannot be optional. Class _functionality_ (behaviour) can
change depending on some conditions

OK, maybe the optional _functionality_ will be enough for me

and for that a simple 'if' statement is often enough

I think simple 'if' isn't enough this time.
But maybe I should think more about that ;J

1. Putting the optional interface in an inherited class.

<shrug> ...and what? If a pointer/reference to the base
class is going to be used, the interface has to still
be _declared_ in the base. It's not optional.

That's why the solution 1 doesn't convince me also.

To prevent that you need smarter users.

I believe they are But I believe also that they're
humans and can make mistakes [unconsciously].

And you need to document your pointer-returning function,
especially in the respect that it returns NULL in case
the optional functionality is unavailable.

I like the Eric Raymond's attitude that the code should be
the only documentation the user needs [in fact, he stated
that according to user interfaces, but the rule is valid
for the source code too].

I'm thinking about some way to achieve this better, because
in my program I have some functionality of a class, which is
optional and I can know if it's available only by checking
that at runtime. But I think that allowing the user to call
this optional interface's methods, and then rewarding the
user with an error, isn't a good solution [though it's
commonly used practice], because the object know well that
the optional interface isn't available BEFORE the user might
call it.

I am not sure what you mean here.

I mean the following is IMO stupid:

SomeClass someObject;
int error = someObject.doSomethingOptional();
if (error) ...;
else ...;

because someObject know BEFORE the user calls doSomethingOptional()
if the optional functionality is available or not. So, if it
knows that it's unavailable, but still allows the user to
call doSomethingOptional() well knowing it'll fail and,
after that, telling the user that HE has made an error,
for me it's very stupid Because it's not the user who
made an error, but the class's designer, who allowed the
user to call the optional functionality which sure will fail.

So I'm searching for a way to allow the user to call that
optional functionality only when it's really available
and disallow it totally if it's not available.

Perhaps dynamic_cast will do what you want:

#include <iostream>

struct B {
virtual void foo() { std::cout << "B::foo()\n"; }
};

struct D : public B {
void bar(){ std::cout << "D::bar()\n"; }
void foo() { std::cout << "D::foo()\n"; }
};

int main()
{
B* obj = new D();
obj->foo();
//obj->bar(); // Error
dynamic_cast<D*>(obj)->bar(); // Works
}

Notice that B has to be a polymorphic type (have a virtual function).

In this case even a static_cast would do nicely.

V

 

[werasm]

Howdy.

Is it possible to write a class with some of its
public interface being optional and dependant of
the runtime circumstances?

I think you could use factory methods to achieve the same effect.
The client calls the factory method to obtain a reference to the
interface he requires. He does not need to know that the
implementation can provide more...

e.g.

struct InterfaceA
{
virtual void do1() = 0;
virtual ~A(){}
};

struct InterfaceB : InterfaceA
{
virtual void do2() = 0;
};

//Hidden somewhere in anonymous namespace in a source file.
struct Impl : InterfaceB
{
};

//Client that requires InterfaceA calls this...
std::auto_ptr<InterfaceA> makeA();
//Implemented as{ return new Impl; }

//Client that requires InterfaceB calls this...
std::auto_ptr<InterfaceB> makeB();
//{ return new Impl; }

The client of InterfaceA does not need to know that InterfaceB
exists, and getting an instance of A only promises what A can
offer. The implementation is hidden away safe and sound, never
for the client to see.

Regards,

Werner

 

[SasQ]

You don't want to tell the user the interface isn't
available (by returning a null pointer)

I can tell him if it's available. Even I have to
Only I don't want to use pointers for that.

nor do you want to give him errors when he invokes
methods on the interface.

Yes, errors are reserved for the situations, when
the user really did something wrong and it's his fault.
Besides, error message can be ignored and then the user
is able to use an empty pointer which will end up with
the program crash.

The only way I can see to achieve that is to not
make the interface optional.

But what could do the Screen class when it receive the
toggleFullScreen() or resizeWindow() messages on
the absence of the window manager? Silently do nothing
and pretending that nothing wrong was happened? Or
passing the buck to the user, telling him it's his fault?
On the system without WM that calls doesn't make any sense
and the Screen class doesn't understand them.

Now, a lot of the solution will depend upon what your
design goals actually are. Do you want the interface to
always be there

No, only if it's available.
That interface might be even delegated to another object,
as my second idea was.

but the implementation loaded only if it's used?

Maybe yes, because the object offering that optional
functionality may be created at runtime.

Do you want to deny functionality unless they install
some add-on?

Yes, it's something in that fashion

My first thought would be a Interface * queryInterface()
sort of approach where you either get back a valid pointer
to the interface or a NULL. If you don't want to return
a NULL, you could throw at this point and make them
deal with it in some other fashion.

And this is the better solution for me Thanks for that!
Throwing an exception is better here than returning an error
or null pointer, because an exception, once thrown, cannot be
ignored, and the following call cannot be executed.

screen.getWindowManager().toggleFullScreen();
//getWindowManager() will throw when the WM isn't available,
//so the toggleFullScreen() will never be called.

Still it's not the Holly Grail i'm searching, but at this
moment it's the best solution.

The nice thing here is that if you just don't want
the overhead of loading the implementation if it isn't needed,
you could have this method create the instance that
implements the interface at this point (much like some of
the singleton patterns).

The memory overhead isn't that important for me.
The most important is an elegant way to make this additional
interface available only when the WM is available.

The problem comes in when the user doesn't know if he has
the interface or not.

Just like in my case He can find out only at runtime.

In this scenareo the user has to test for the presence
of the interface in order to take the correct code path.

I agree

Personally I would be really annoyed at a error from the
interface methods.

Me too. Because they're not my/your/user's errors
The error is to make this optional functionality available
when there's no way to support it.

Thanks for advices, they were very useful, especially
that with throwing an exception.

 

[Victor Bazarov]

[..]
But what could do the Screen class when it receive the
toggleFullScreen() or resizeWindow() messages on
the absence of the window manager? Silently do nothing
and pretending that nothing wrong was happened? Or
passing the buck to the user, telling him it's his fault?
On the system without WM that calls doesn't make any sense
and the Screen class doesn't understand them.

So, what you're saying is that on a different system (the one
without a WM, for instance) it would be a _different_ Screen
class, right? Then it would be a different application, no?

Joe Greer:

And this is the better solution for me Thanks for that!
Throwing an exception is better here than returning an error
or null pointer, because an exception, once thrown, cannot be
ignored, and the following call cannot be executed.

screen.getWindowManager().toggleFullScreen();
//getWindowManager() will throw when the WM isn't available,
//so the toggleFullScreen() will never be called.

I believe you're still confused. For this code to compile, the
'toggleFullScreen' member has to be present in the manager so
the code is _compileable_. IOW, your 'screen' will have to have
'getWindowManager' member function which will *pretend* to return
some WM (say, by reference), but instead it will throw. Now, is
it not cheating the user? I thought you're after some kind of
system in which at _compile-time_ the user cannot even write
an expression like that...

Still it's not the Holly Grail i'm searching, but at this
moment it's the best solution.

How is this "the best"? The user will get an exception, and it
will say something like "attempt to get a window manager on
a system that doesn't have any". So the user will *still* have
to have a way to prevent that from happening, e.g. by calling
some member like

if (screen.hasWindowManager()) {
// do the "optional" stuff
}

otherwise there is no way for the user to prevent the exceptions
from being thrown.

So, now you're back to plain old polymorphism where your 'screen'
implementation can either have or not have a Window Manager, who
in turn can either have or not have a full screen capability, and
so forth. Why do you keep insisting on some other way? Why does
not polymorphism work for you?

[..]

V

 

[SasQ]

So, what you're saying is that on a different system
(the one without a WM, for instance) it would be a
_different_ Screen class, right? Then it would be a
different application, no?

The system having WM could be used with or without WM.
The system not having WM could be used only the second way.

I think it doesn't necessary have to be one Screen class,
the optional functionality could be dissected into separate
class, like in my second idea mentioned earier
[WindowManager class].

I believe you're still confused.

Your belief is right But, like I've said, it's the best
solution up to now.

For this code to compile, the 'toggleFullScreen' member
has to be present in the manager

And it could be. The WindowManager class could do that.

so the code is _compileable_. IOW, your 'screen' will have
to have 'getWindowManager' member function which will
*pretend* to return some WM (say, by reference), but
instead it will throw. Now, is it not cheating the user?

Hmm... Yes, looks like it's not the best idea :/

WindowManager& wm = screenWithoutWM.getWindowManager();
//screenWithoutWM: "What?! I don't have any WM and I don't
//even know what it is! What do you want from me?"

I thought you're after some kind of system in which at
_compile-time_ the user cannot even write an expression
like that...

It's something in the middle :| On one hand the user doesn't
know at compile time if the WM is available, so he has to
figure it out at runtime - ask if it's available and then use.
But on the other hand he shouldn't be able to use it if it
isn't available at runtime. He have to ask first, before use,
and this should be required by the code design itself, not
by some documentation which noone reads carefully or
remember ;-J

How is this "the best"? The user will get an exception, and it
will say something like "attempt to get a window manager on
a system that doesn't have any". So the user will *still* have
to have a way to prevent that from happening, e.g. by calling
some member like

if (screen.hasWindowManager()) {
// do the "optional" stuff
}

otherwise there is no way for the user to prevent the exceptions
from being thrown.

Yes of course. But this time if he forget to do this, he
won't be able to proceed as if nothing was happened - he'll
receive an exception and if he doesn't handle it, the program
won't proceed to use unavailable WindowManager object.
In the previous example [with returning an error or null pointer]
the user was able to ignore it [by mistake] and proceed to use
invalid pointer or non-existent WindowManager object.
So, it's not the best idea, but better than the previous one
I think.

So, now you're back to plain old polymorphism where your
'screen' implementation can either have or not have a
Window Manager, who in turn can either have or not have
a full screen capability, and so forth. Why do you keep
insisting on some other way? Why does not polymorphism
work for you?

Because I don't see polymorphism here :/
If it were plain polymorphism, the user could use the Screen
class the same way, no matter if WM is available or not,
because the implementation would handle it. But the user
have to have access to that additional functionality if
it's available, which is impossible when accessing it by
the base class [it doesn't understand the optional messages
concerning swithing to fullscreen or manipulating window].
Or maybe there IS some way to access it through base class
with use of polymorphism?

I think rather about some separate class to manipulate
that windowing stuff, but related some way to the Screen
class. But I don't know a good way to access it only
when it is available at runtime.
The important thing is here that if the WM is available
at runtime, this fact is known even before main() is called,
and the WM is available all the time the program run.