Result And Optional Types

A function that returns int and uses -1 to mean "failed" has a bug built into its interface: nothing stops the value from being used as if it were a real answer, because the type system cannot see the difference between "the result is -1" and "there is no result". The same trap catches 0.0 for a failed calculation that could legitimately return zero, and "" for a lookup that failed versus one whose value genuinely is empty - the division and lookup examples in the demo hit exactly these two cases side by side. ResultInt, ResultDouble and ResultString fix this the ordinary way: a struct with an explicit ok flag, the value, and - only when ok is false - an error code and message. The value only means something once ok has been checked, and that check is visible in the caller's own code instead of being an unwritten convention the next person maintaining it has to already know. Three parallel types exist because neither MQL4 nor MQL5 offers a template mechanism that would keep this pattern this simple across an int/double/string value type plus an error code and message. A single generic Result<T> is not worth simulating with macros or void pointers - that trades one kind of hidden bug for another. Three small, obviously-correct types are the honest version of the same idea, and the same reasoning holds on both platforms. Each type ships the same four operations: an Ok constructor, a Fail constructor, ValueOr for the common "unwrap with a default" shape, and Unwrap for the case where the caller has already checked .ok and just wants the value without retyping it - calling Unwrap on a failed result cannot throw (neither platform has exceptions), so it prints a loud Journal warning and returns a zero value instead, which is itself the signal that something called Unwrap without checking .ok first. The header is self-contained. No dependencies, no DLLs, plain structs and plain functions. Notes and limitations - Only int, double and string are provided. There is no generic Result<T> - neither platform's template support makes that worthwhile here, and three explicit, readable types are preferable to simulating generics with tricks that make the failure mode harder to see, not easier. - Unwrap cannot throw. Calling it on a failed result is a programming error in the caller, and the loud Print is deliberately the only signal - this header will not stop program flow on your behalf, because neither platform gives it a safe way to do so. - These are plain value structs, not classes - copying a Result copies its string fields too, which is normal struct-copy cost on both platforms and is not a concern at the call frequency this pattern is meant for (validation, parsing, lookups), not a tight per-tick inner loop. - This header expresses "did it work and what did I get", not a general error taxonomy. Pair it with retry/classification logic (IsRetryableError style on MQL4, TRADE_RETCODE_* classification on MQL5) where that is separately needed - that is a different concern and deliberately not folded in here.

Script · MT4 · v1.0 · Free

Tags: MT4 Script · MQL4 Source Code

MQL4 & MQL5 scripts · PolyMaria