New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service methods should be possible to specify its error type #38

Closed
dahlia opened this Issue Aug 4, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@dahlia
Member

dahlia commented Aug 4, 2016

Although we can declare every Either-like union types to represent successful/failed result of methods, there are several downsides:

  • As Nirum currently doesn't have generics, we need to declare many lookalike union types.
  • Although some programming languages having algebraic data type (e.g. Haskell, Rust, Swift) tend to deal with errors through Either-like union type, such approach to represent errors is not that natural to many programming languages having exceptions (e.g. Java, Python, JavaScript). It would be great if errors can be dealt in the most natural way of each programming language.

If service methods can have an error type alongside of a return type errors can be dealt in multiple ways so that each language target choose its own translation to represent errors in the most natural way of the language.

For example:

union image-lookup-error = missing-image | moderated-image (text reason);

service image-service (
    hash upload (blob image),
    uri lookup (hash image-hash): image-lookup-error,
);

(The : error-type syntax is just a pseudocode.) The the above code can be compiled to Haskell using Either monad:

data ImageLookupError = MissingImage | ModeratedImage { reason :: Text } deriving (Eq, Ord, Show)

class ImageService s where
    upload :: s -> ByteString -> Hash
    lookup :: s -> Hash -> Either ImageLookupError URL

whereas be compiled to Java using checked exceptions:

// Of course, we need to annotate so that Java target compile `image-lookup-error` to a class subclassing `Exception`.
final public class ImageLookupError extends Exception {}
final public class MissingImage extends ImageLookupError {}
final public class ModeratedImage extends ImageLookupError {
    final protected String reason;
    public ModeratedImage(final String reason) {
        super();
        this.reason = reason;
    }
    // omit other overloaded constructors...
    public String getReason() {
        return reason;
    }
}

public interface ImageService {
    public Hash upload(final byte[] image);
    public URI lookup(final Hash imageHash) throws ImageLookupError;
}

@dahlia dahlia added the typ:enhance label Aug 4, 2016

@Kroisse Kroisse self-assigned this Aug 12, 2016

@dahlia

This comment has been minimized.

Member

dahlia commented Aug 12, 2016

Design critics by @Kroisse. The current design forces analyzer to determine whether the type need to inherit Exception (or any other similar things) when the type is referred as an error type of any method, not it's declared.

I am with him. Even worse, it doesn't make sense at all when primitive types (e.g. text, bigint) are used as an error type. How can we make str or int type to inherit Exception in Python?

Several workarounds come to my mind, but any of them are sufficient. For instance, we can generate a wrapper subclass of Exception, and make it to hold the actual error value. The problem is, we can't utilize catch a specific error case even if the actual error type is an union type. Wrapper makes it hard to achieve precise exception handling.

Anyway the design should be adjusted.

@dahlia

This comment has been minimized.

Member

dahlia commented Aug 12, 2016

A good idea from @Kroisse: Annotating types to be used as an error types e.g.:

@error
union image-lookup-error = missing-image | moderated-image (text reason);

(Although we currently don't have annotations without arguments. Annotation syntax also has to be adjusted.)

@kanghyojun

This comment has been minimized.

Member

kanghyojun commented Apr 20, 2017

nirum-lang/nirum-python#71 is following issue. since nirum compiler dosen't need to be updated anymore, i close this issue.

@kanghyojun kanghyojun closed this Apr 20, 2017

@dahlia dahlia reopened this Jun 21, 2017

@dahlia

This comment has been minimized.

Member

dahlia commented Jun 21, 2017

Service clients don't process error values from the service server. Need to fix this to close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment