Skip to main content
replaced http://softwareengineering.stackexchange.com/ with https://softwareengineering.stackexchange.com/
Source Link

One consideration is that the try - catch block is not the issue. (Based on my comments to the question above).

The main problem is that the North property is an I/O call.

At that point in the code's execution, the program needs to check the I/O provided by the client code. (It would not be relevant that the input is in the form of a delegate, or that the input was, nominally, passed in already).

Once you lose control of the input, you cannot ensure the function is pure. (Especially if the function can throw).


I'm not clear why you do not want to check on the call to Move[Check]Room? As per my comment to the question:

Yes. What do you when executing the delegate may only work the first time, or return a different room on the second call? Calling the delegate can be considered / cause a side effect itself?

As Bart van Ingen Schenau said above,

Your Create function does not protect you from getting an exception when getting the property. If your delegate throws, in real life it is very likely that it will thrown only under some conditions. Chances are that the conditions for throwing are not present during construction, but they are present when getting the property.

In general, any type of lazy loading implicitly defers the errors until that point.


I would suggest using a Move[Check]Room method. This would allow you to separate the impure I/O aspects into one place.

Similar to Robert Harvey'sRobert Harvey's answer:

To make it a pure function, return an actual object that encapsulates the expected value from the function and a value indicating a possible error condition, like a Maybe object or a Unit of Work object.

It would be up to the code writer to determine how to handle the (possible) exception from the input. Then the method can return a Room object, or a Null Room object, or perhaps bubble out the exception.

It this point it depends on:

  • Does the Room domain treat Room Exceptions as Null or Something Worse.
  • How to notify the client code calling North on a Null / Exception Room. (Bail / Status Variable / Global State / Return a Monad / Whatever; Some are more pure then others :) ).

One consideration is that the try - catch block is not the issue. (Based on my comments to the question above).

The main problem is that the North property is an I/O call.

At that point in the code's execution, the program needs to check the I/O provided by the client code. (It would not be relevant that the input is in the form of a delegate, or that the input was, nominally, passed in already).

Once you lose control of the input, you cannot ensure the function is pure. (Especially if the function can throw).


I'm not clear why you do not want to check on the call to Move[Check]Room? As per my comment to the question:

Yes. What do you when executing the delegate may only work the first time, or return a different room on the second call? Calling the delegate can be considered / cause a side effect itself?

As Bart van Ingen Schenau said above,

Your Create function does not protect you from getting an exception when getting the property. If your delegate throws, in real life it is very likely that it will thrown only under some conditions. Chances are that the conditions for throwing are not present during construction, but they are present when getting the property.

In general, any type of lazy loading implicitly defers the errors until that point.


I would suggest using a Move[Check]Room method. This would allow you to separate the impure I/O aspects into one place.

Similar to Robert Harvey's answer:

To make it a pure function, return an actual object that encapsulates the expected value from the function and a value indicating a possible error condition, like a Maybe object or a Unit of Work object.

It would be up to the code writer to determine how to handle the (possible) exception from the input. Then the method can return a Room object, or a Null Room object, or perhaps bubble out the exception.

It this point it depends on:

  • Does the Room domain treat Room Exceptions as Null or Something Worse.
  • How to notify the client code calling North on a Null / Exception Room. (Bail / Status Variable / Global State / Return a Monad / Whatever; Some are more pure then others :) ).

One consideration is that the try - catch block is not the issue. (Based on my comments to the question above).

The main problem is that the North property is an I/O call.

At that point in the code's execution, the program needs to check the I/O provided by the client code. (It would not be relevant that the input is in the form of a delegate, or that the input was, nominally, passed in already).

Once you lose control of the input, you cannot ensure the function is pure. (Especially if the function can throw).


I'm not clear why you do not want to check on the call to Move[Check]Room? As per my comment to the question:

Yes. What do you when executing the delegate may only work the first time, or return a different room on the second call? Calling the delegate can be considered / cause a side effect itself?

As Bart van Ingen Schenau said above,

Your Create function does not protect you from getting an exception when getting the property. If your delegate throws, in real life it is very likely that it will thrown only under some conditions. Chances are that the conditions for throwing are not present during construction, but they are present when getting the property.

In general, any type of lazy loading implicitly defers the errors until that point.


I would suggest using a Move[Check]Room method. This would allow you to separate the impure I/O aspects into one place.

Similar to Robert Harvey's answer:

To make it a pure function, return an actual object that encapsulates the expected value from the function and a value indicating a possible error condition, like a Maybe object or a Unit of Work object.

It would be up to the code writer to determine how to handle the (possible) exception from the input. Then the method can return a Room object, or a Null Room object, or perhaps bubble out the exception.

It this point it depends on:

  • Does the Room domain treat Room Exceptions as Null or Something Worse.
  • How to notify the client code calling North on a Null / Exception Room. (Bail / Status Variable / Global State / Return a Monad / Whatever; Some are more pure then others :) ).
Source Link
SH-
  • 159
  • 2

One consideration is that the try - catch block is not the issue. (Based on my comments to the question above).

The main problem is that the North property is an I/O call.

At that point in the code's execution, the program needs to check the I/O provided by the client code. (It would not be relevant that the input is in the form of a delegate, or that the input was, nominally, passed in already).

Once you lose control of the input, you cannot ensure the function is pure. (Especially if the function can throw).


I'm not clear why you do not want to check on the call to Move[Check]Room? As per my comment to the question:

Yes. What do you when executing the delegate may only work the first time, or return a different room on the second call? Calling the delegate can be considered / cause a side effect itself?

As Bart van Ingen Schenau said above,

Your Create function does not protect you from getting an exception when getting the property. If your delegate throws, in real life it is very likely that it will thrown only under some conditions. Chances are that the conditions for throwing are not present during construction, but they are present when getting the property.

In general, any type of lazy loading implicitly defers the errors until that point.


I would suggest using a Move[Check]Room method. This would allow you to separate the impure I/O aspects into one place.

Similar to Robert Harvey's answer:

To make it a pure function, return an actual object that encapsulates the expected value from the function and a value indicating a possible error condition, like a Maybe object or a Unit of Work object.

It would be up to the code writer to determine how to handle the (possible) exception from the input. Then the method can return a Room object, or a Null Room object, or perhaps bubble out the exception.

It this point it depends on:

  • Does the Room domain treat Room Exceptions as Null or Something Worse.
  • How to notify the client code calling North on a Null / Exception Room. (Bail / Status Variable / Global State / Return a Monad / Whatever; Some are more pure then others :) ).