Javascript design pattern question. I want to transform a record but it might fail if the SO is already closed (or for other reasons). Can I try / catch the transform then return false in the catch so the caller can act on the returned boolean false? When the function is a success, it returns the transformed record. This means that my function is effectively returning TWO different types: either a boolean or a record. I don't like the idea of returning more than one type from a function... maybe JS people think this is ok though?

Agreed you probably don't want a function that would return a successful result or false for an error, but if it gets the job done, then it gets the job done. Seems like you are really asking about a design pattern for good error handling. Are you familiar with using callback functions, Promises, and/or async/await? Not sure if you writing SuiteScript code or actualy JS

Personally I would return

null

(not false) if the transform failed

imho idiomatic javascript would handle this in one of two ways. Either swallow the error and return a nothing such as @michoel suggests, or embrace exception handling - either allow the original exception to bubble up or catch it and throw your own, potentially more useful exception. Using the exception approach avoids the notion of returning different types of results from your function. Using the 'null' approach is more "functional" in nature - if you don't like or want to ignore the exception handling feature of the language. If you wanted to be even more "functional" you would have that function return a

Maybe<TransformedRecordType>

or

Option<TransformedRecordType>

to represent the presence of lack thereof of a valid record without doing low level

null

handling and still returning one type.

@stalbert I could let the function return with the unhandled excetion then do something in the caller?

Yes, the rule of thumb I apply when using exception handling is to not catch exceptions unless you have something specific to do with them - otherwise let them bubble up to the caller.

Please don't be like the contractor who wrote the code I've inherited now. Every function in the codebase looks like this 👿

function doSomething() {
  try {
    // do something
  } catch(error) {
    emailErrorReport(error);
  }
}

lol - that's not the intention 🙂

exactly - if you don't have a business domain reason to catch an exception, don't.

Swallowing the exception with that one

Those emails don't go anywhere (hardcoded email address to defunct mailbox), so it's basically the equivalent

hah, that's even worse, not to mention the system overhead of trying to email