We Keep Coding

How to use `throw` properly in try...catch block when other unexpected errors might occur?

The title may not be the best.
Code sample:
a = 1;
try {
if (a == 1) {
throw ('My fake error.');
}
} catch (err) {
console.log(err.message);
}
Assume I have more complex code in the try block. If a statement in that try block throws an error I can get the text of the error by looking at err.message. But, if I throw an error myself I can only see the text if I look at err because err.message is undefined.
How do I catch both unexpected errors, and errors I throw in the same catch block without writing more complex code to see if err.message is null for instance? I would expect both to return a similar structure, but they do not.

A good approach to this sort of issue is to always throw Error objects, and not literals.
It is considered good practice to only throw the Error object itself or an object using the Error object as base objects for user-defined exceptions. The fundamental benefit of Error objects is that they automatically keep track of where they were built and originated.
If you throw a plain non-error value, that value will be the expression in the catch section - which will (probably) not have the .message (or .stack) property, and be less than useful as a result.
So, replace throw ('My fake error.'); with throw new Error('My fake error.'); - and then, in catch, doing console.log(err.message) may log either My fake error., or it may log whatever other unexpected error occurred, if the rest of the code around there is well structured enough to always throw Error objects. Just enabling and following that no-throw-literal ESLint rule referenced above would be sufficient.

is it good practice to use try inside try block to catch different errors? - JavaScript

I am using try catch inside try block to print relative message or get to know in which method error happened.
code snippet
for (const searchUrl of savedSearchUrls) {
console.log("here");
// function will get all the links of profiles in saved search url
try {
const links = await scrapeFromurl(browser, searchUrl);
try {
saveToDatabase(links);
} catch (e) {
handleError(e, "eror while saving to database");
}
} catch (err) {
handleError(err, "error in scrapeFromurl()");
}
}
I have searched on google but couldn't find related topic.
what are the other ways to accomplish similar things?
what are the best practice to handle this type of situation.

I would suggest using only one try catch block and specific error instances for each method, then in catch block you can simply check which method throws an error by using instanceof operator
class ScrapeError extends Error {
message = "error in scrapeFromurl()"
}
class DBError extends Error {
message = "eror while saving to database"
}
async function scrapeFromurl() {
throw new ScrapeError();
}
async function saveToDatabase(links) {
throw new DBError();
}
async function main() {
try {
const links = await scrapeFromurl();
await saveToDatabase(links);
} catch (e) {
if (e instanceof ScrapeError) {
console.log('scrape', e);
}
if (e instanceof DBError) {
console.log('dberror', e);
}
}
}
main();

By default a single try-catch block is enough without needs for nesting other try-catches into it. However, there may be some legitimate exceptions from these rules.
Exception 1: Different handlers for the same exception
Let's consider the following example
try {
myroutine(); // may throw three types of exceptions
} catch (e) {
if (e instanceof TypeError) {
// statements to handle TypeError exceptions
} else if (e instanceof RangeError) {
// statements to handle RangeError exceptions
} else if (e instanceof EvalError) {
// statements to handle EvalError exceptions
} else {
// statements to handle any unspecified exceptions
logMyErrors(e); // pass exception object to error handler
}
}
It is perfectly possible that inside your try there is a section where a given error type, like a RangeError needs a different way of handling than the main catch. In this case it might make sense to have another try-catch inside your try, albeit, in this case, for better readability it would make sense to consider the inner try as a method and call that, so you would not physically nest the try-catch blocks, but separate the concerns of the try-catches into separate methods.
Exception 2: Handling a certain type of error only at a section of a try-block
It is quite possible that you want your try-catch to throw the error further in the majority of your try block, but, in a specific section you want it to handle it. Again, in this case it would make sense to separate the inner try into its own method.
Conclusion
Having nested try-catches are nonintuitive for a reader, therefore it makes sense to separate the inner try into its own method whenever you encounter the need to nest tries. Yet, as the examples above show, there are legitimate needs to drift away from the outer handling of an error for some sections. However, by default it is a good idea to consider such sections as separate concerns worthy of separating from the method. Of course, sometimes you might want to keep nested try-catches without separating their concerns, but more often than not it is worth to apply the separations. So, a rule of thumb that you may want to consider is to refactor nested try-catches either into separate methods or a single try-catch, unless there is a very good reason not to do so.

In asyncronous scripts you can use domains for error handling. And trycatch in trycatch can be treated like domain in domain, which is pointless.
Moreover, programmers always tend to prevent the code from growing horizontally like this
{
...
{
...
{
... (and so on)
{
}
}
}
}
So it is a really bad idea. I can keep on telling drawbacks of this approach, but not going to. Just use one trycatch with switchcase inside to handle all errors

Catch invalid variable name with SyntaxError

First off the catch clause isn't being executed. But I am getting "SyntaxError: missing exponent" error in the browser. I'm wondering if it's because of load time? Or my setup is not right.
I want to make a custom error for incorrect variable name.
try {
var 1ele = 1;
} catch (error) {
if (error instanceOf SyntaxError) {
throw new SyntaxError("There is a syntax error!");
}
}
Thanks for the help.

You have introduced a Syntax error in your code var 1ele = 1; and intend to catch the error to display a custom error message. However this won't work in the way you have written now since the Syntax error will cause the JavaScript parser to stop soon after encountering the Syntax error. The catch part of your code will never be reached.
However, you can implement the same using an eval statement. Try the code below.
try {
eval("var 1ele = 1");
} catch (error) {
if (error instanceof SyntaxError) {
throw new SyntaxError("There is a syntax error!");
}
}
Here, I have wrapped the Syntax error causing variable declaration inside an eval function. This will cause the syntax error only in the environment where the eval statement is executed and not your main code. You will be able to catch the error and display your custom message.
NOTE 1: You are getting the "SyntaxError: missing exponent" error message because your variable name starts with 1e which makes the JavaScript parser think that it is a number in exponential format.
NOTE 2: You have used instanceOf in your code. It is actually instanceof (with a lower case o). Ref

How to fix "'throw' of exception caught locally"?

In this function that handles a REST API call, any of the called functions to handle parts of the request might throw an error to signal that an error code should be sent as response. However, the function itself might also discover an error, at which point it should jump into the exception handling block.
static async handleRequest(req) {
try {
let isAllowed = await checkIfIsAllowed(req);
if (!isAllowed) {
throw new ForbiddenException("You're not allowed to do that.");
}
let result = await doSomething(req); // can also raise exceptions
sendResult(result);
} catch(err) {
sendErrorCode(err);
}
}
Webstorm will underline the throw with the following message: 'throw' of exception caught locally. This inspection reports any instances of JavaScript throw statements whose exceptions are always caught by containing try statements. Using throw statements as a "goto" to change the local flow of control is likely to be confusing.
However, I'm not sure how to refactor the code to improve the situation.
I could copypaste the code from the catch block into the if check, but I believe this would make my code less readable and harder to maintain.
I could write a new function that does the isAllowed check and throws an exception if it doesn't succeed, but that seems to be sidestepping the issue, rather than fixing a design problem that Webstorm is supposedly reporting.
Are we using exceptions in a bad way, and that's why we're encountering this problem, or is the Webstorm error simply misguiding and should be disabled?

Contrary to James Thorpe's opinion, I slightly prefer the pattern of throwing. I don't see any compelling reason to treat local errors in the try block any differently from errors that bubble up from deeper in the call stack... just throw them. In my opinion, this is a better application of consistency.
Because this pattern is more consistent, it naturally lends itself better to refactoring when you want to extract logic in the try block to another function that is perhaps in another module/file.
// main.js
try {
if (!data) throw Error('missing data')
} catch (error) {
handleError(error)
}
// Refactor...
// validate.js
function checkData(data) {
if (!data) throw Error('missing data')
}
// main.js
try {
checkData(data)
} catch (error) {
handleError(error)
}
If instead of throwing in the try block you handle the error, then the logic has to change if you refactor it outside of the try block.
In addition, handling the error has the drawback of making you remember to return early so that the try block doesn't continue to execute logic after the error is encountered. This can be quite easy to forget.
try {
if (!data) {
handleError(error)
return // if you forget this, you might execute code you didn't mean to. this isn't a problem with throw.
}
// more logic down here
} catch (error) {
handleError(error)
}
If you're concerned about which method is more performant, you shouldn't be. Handling the error is technically more performant, but the difference between the two is absolutely trivial.
Consider the possibility that WebStorm is a bit too opinionated here. ESLint doesn't even have a rule for this. Either pattern is completely valid.

You're checking for something and throwing an exception if isAllowed fails, but you know what to do in that situation - call sendErrorCode. You should throw exceptions to external callers if you don't know how to handle the situation - ie in exceptional circumstances.
In this case you already have a defined process of what to do if this happens - just use it directly without the indirect throw/catch:
static async handleRequest(req) {
try {
let isAllowed = await checkIfIsAllowed(req);
if (!isAllowed) {
sendErrorCode("You're not allowed to do that.");
return;
}
let result = await doSomething(req); // can also raise exceptions
sendResult(result);
} catch(err) {
sendErrorCode(err);
}
}
I could copypaste the code from the catch block into the ifcheck, but I believe this would make my code less readable and harder to maintain.
On the contrary, as above, I would expect this to be the way to handle this situation.

Since this is not a blocking error, but only an IDE recommendation, then the question should be viewed from two sides.
The first side is performance. If this is a bottleneck and it is potentially possible to use it with compilation or when transferring to new (not yet released) versions of nodejs, the presence of repetitions is not always a bad solution. It seems that the IDE hints precisely in this case and that such a design can lead to poor optimization in some cases.
The second side is the code design. If it will make the code more readable and simplify the work for other developers - keep it. From this point of view, solutions have already been proposed above.

Return a promise reject instead of throwing error in the try block
try {
const isAllowed = await checkIfIsAllowed(request);
if (!isAllowed) {
return Promise.reject(Error("You're not allowed to do that."));
}
const result = await doSomething(request);
sendResult(result);
} catch (error) {
throw error;
}

There are good answers to the question "Why not use exceptions as normal flow control?" here.
The reason not to throw an exception that you will catch locally is that you locally know how to handle that situation, so it is, by definition, not exceptional.
#James Thorpe's answer looks good to me, but #matchish feels it violates DRY. I say that in general, it does not. DRY, which stands for Don't Repeat Yourself, is defined by the people who coined the phrase as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". As applied to writing software code, it is about not repeating complex code.
Practically any code that is said to violate DRY is said to be "fixed" by extracting the repeated code into a function and then calling that function from the places it was previously repeated. Having multiple parts of your code call sendErrorCode is the solution to fixing a DRY problem. All of the knowledge of what to do with the error is in one definitive place, namely the sendErrorCode function.
I would modify #James Thorpe's answer slightly, but it is more of a quibble than a real criticism, which is that sendErrorCode should be receiving exception objects or strings but not both:
static async handleRequest(req) {
try {
let isAllowed = await checkIfIsAllowed(req);
if (!isAllowed) {
sendErrorCode(new ForbiddenException("You're not allowed to do that."));
return;
}
let result = await doSomething(req); // can also raise exceptions
sendResult(result);
} catch(err) {
sendErrorCode(err);
}
}
The larger question is what is the likelihood of the error and is it appropriate to treat !isAllowed as an exception. Exceptions are meant to handle unusual or unpredictable situations. I would expect !isAllowed to be a normal occurrence that should be handled with logic specific to that situation, unlike, say, a sudden inability to query the database that has the answer to the isAllowed question.
#matchish's proposed solution changes the contract of doSomethingOnAllowedRequest from something that will never throw an exception to something that will routinely throw an exception, placing the burden of exception handling on all of its callers. This is likely to cause a violation of DRY by causing multiple callers to have repetitions of the same error handling code, so in the abstract I do not like it. In practice, it would depend on the overall situation, such as how many callers are there and do they, in fact, share the same response to errors.

Answer of James Thorpe has one disadvantage on my opinion. It's not DRY, in both cases when you call sendError you handle Exceptions. Let's imagine we have many lines of code with logic like this where Exception can be thrown. I think it can be better.
This is my solution
async function doSomethingOnAllowedRequest(req) {
let isAllowed = await checkIfIsAllowed(req);
if (!isAllowed) {
throw new ForbiddenException("You're not allowed to do that.");
}
doSomething(req);
}
static async handleRequest(req) {
try {
let result = await doSomethingOnAllowedRequest(req);
sendResult(result);
} catch(err) {
sendErrorCode(err);
}
}

This could give you some tips, maybe that can be the cause(not sure if relevant).
Catch statement does not catch thrown error
"
The reason why your try catch block is failing is because an ajax request is asynchronous. The try catch block will execute before the Ajax call and send the request itself, but the error is thrown when the result is returned, AT A LATER POINT IN TIME.
When the try catch block is executed, there is no error. When the error is thrown, there is no try catch. If you need try catch for ajax requests, always put ajax try catch blocks inside the success callback, NEVER outside of it."

throw vs throw new Error [duplicate]

I want to write a common error handler which will catch custom errors thrown on purpose at any instance of the code.
When I did throw new Error('sample') like in the following code
try {
throw new Error({'hehe':'haha'});
// throw new Error('hehe');
} catch(e) {
alert(e);
console.log(e);
}
Log shows in Firefox as Error: [object Object] and I couldn’t parse the object.
For the second throw the log shows as: Error: hehe
Whereas when I did
try {
throw ({'hehe':'haha'});
} catch(e) {
alert(e);
console.log(e);
}
the console showed as: Object { hehe="haha"} in which I was able to access the error properties.
What is the difference?
Is the difference as seen in the code? Like string will be just passed as string and object as objects but the syntax will be different?
I haven’t explored throwing error object… I had done only throwing strings.
Is there any other way than the above two mentioned methods?

The difference between 'throw new Error' and 'throw someObject' in javascript is that throw new Error wraps the error passed to it in the following format −
{ name: 'Error', message: 'String you pass in the constructor'
}
The throw someObject will throw the object as is and will not allow any further code execution from the try block, ie same as throw new Error.
Here is a good explanation about The Error object and throwing your own errors
The Error Object
Just what we can extract from it in an event of an error? The Error object in all browsers support the following two properties:
name: The name of the error, or more specifically, the name of the constructor function the error belongs to.
message: A description of the error, with this description varying depending on the browser.
Six possible values can be returned by the name property, which as mentioned correspond to the names of the error's constructors. They are:
Error Name Description
EvalError An error in the eval() function has occurred.
RangeError Out of range number value has occurred.
ReferenceError An illegal reference has occurred.
SyntaxError A syntax error within code inside the eval() function has occurred.
All other syntax errors are not caught by try/catch/finally, and will
trigger the default browser error message associated with the error.
To catch actual syntax errors, you may use the onerror event.
TypeError An error in the expected variable type has occurred.
URIError An error when encoding or decoding the URI has occurred
(ie: when calling encodeURI()).
Throwing your own errors (exceptions)
Instead of waiting for one of the 6 types of errors to occur before control is automatically transferred from the try block to the catch block, you can also explicitly throw your own exceptions to force that to happen on demand. This is great for creating your own definitions of what an error is and when control should be transferred to catch.

throw "I'm Evil"
throw will terminate the further execution & expose message string on catch the error.
try {
throw "I'm Evil"
console.log("You'll never reach to me", 123465)
} catch (e) {
console.log(e); // I'm Evil
}
Console after throw will never be reached cause of termination.
throw new Error("I'm Evil")
throw new Error exposes an error event with two params name & message. It also terminate further execution
try {
throw new Error("I'm Evil")
console.log("You'll never reach to me", 123465)
} catch (e) {
console.log(e.name, e.message); // Error I'm Evil
}
throw Error("I'm Evil")
And just for completeness, this works also, though is not technically the correct way to do it -
try {
throw Error("I'm Evil")
console.log("You'll never reach to me", 123465)
} catch (e) {
console.log(e.name, e.message); // Error I'm Evil
}
console.log(typeof(new Error("hello"))) // object
console.log(typeof(Error)) // function

The following article perhaps goes into some more detail as to which is a better choice; throw 'An error' or throw new Error('An error'):
http://www.nczonline.net/blog/2009/03/10/the-art-of-throwing-javascript-errors-part-2/
It suggests that the latter (new Error()) is more reliable, since browsers like Internet Explorer and Safari (unsure of versions) don't correctly report the message when using the former.
Doing so will cause an error to be thrown, but not all browsers respond the way you’d expect. Firefox, Opera, and Chrome each display an “uncaught exception” message and then include the message string. Safari and Internet Explorer simply throw an “uncaught exception” error and don’t provide the message string at all. Clearly, this is suboptimal from a debugging point of view.

TLDR: they are equivalent Error(x) === new Error(x).
// this:
const x = Error('I was created using a function call!');
​​​​// has the same functionality as this:
const y = new Error('I was constructed via the "new" keyword!');
source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error
throw and throw Error are functionally equivalent. But when you catch them and serialize them to console.log they are not serialized exactly the same way:
throw 'Parameter is not a number!';
throw new Error('Parameter is not a number!');
throw Error('Parameter is not a number!');
Console.log(e) of the above will produce 2 different results:
Parameter is not a number!
Error: Parameter is not a number!
Error: Parameter is not a number!

You first mention this code:
throw new Error('sample')
and then in your first example you write:
throw new Error({'hehe':'haha'})
The first Error object would actually be useful, because it is expecting a string value, in this case 'sample'. The second would not because you are trying to pass an object in, and it is expecting a string, and would not display a helpful error.
The error object would have the "message" property, which would be 'sample'.

The Error constructor is used to create an error object. Error objects are thrown when runtime errors occur. The Error object can also be used as a base object for user-defined exceptions.
User-defined Errors are thrown via the throw statement. program control will be passed to the first catch block in the call stack.
The difference between throwing an error with and without Error object:
throw {'hehe':'haha'};
In chrome devtools looks like this:
Chrome tells us that we have an uncaught error which just is a JS object. The object itself could have information regarding the error but we still don't know immediately where it came from. Not very useful when we are working on our code and debugging it.
throw new Error({'hehe':'haha'});
In chrome devtools looks like this:
An error thrown with the Error object gives us a stack trace when we expand it. This gives us valuable information where the error precisely came from which is often valuable information when debugging your code. Further note that the error says [object Object], this is because the Error constructor expects a message string as a first argument. When it receives a object it will coerce it into a string.

you can throw as object
throw ({message: 'This Failed'})
then for example in your try/catch
try {
//
} catch(e) {
console.log(e); //{message: 'This Failed'}
console.log(e.message); //This Failed
}
or just throw a string error
throw ('Your error')
try {
//
} catch(e) {
console.log(e); //Your error
}
throw new Error //only accept a string

TLDR
throw new Error('problem') captures a number of properties of the place where the error happened.
throw 'problem' does not
new Error('message') captures the execution stack + others
Using an Error object allows you to capture the execution stack at the point where you throw the error. So when the error gets passed up the error handling tree, so does this stack snapshot.
So inserting throw "test error" somewhere in my codebase results in:
Whereas throw new Error('test error') results in:
You can see that the native Error object captures the stack at the point I throw the error and makes it available to whatever captures the error. That makes it easier for me to trace the problem when I'm debugging it.
In addition to that it also captures properties such as fileName, lineNumber and columnNumber.
If you use the stack trace it's there for exception trackers to log for you
In this case the stack is being printed into the browser console but if you're using Javascript error logging tools like Appsignal or Bugsnag then that stack will also be available in them too. If you inspect the error object you can access the stack snapshot directly:
err = new Error('test')
err.stack
The heuristic I use for deciding which format to use
When I don't plan to catch the exception I use new Error('problem')
When I'm throwing an error because something unexpected or out-of-bounds has happened in the application, let's say the local datastore is corrupted, I might be in a situation where I don't want to handle it, but I do want to flag it. In this case I'll use the Error object so I have that stack snapshot.
By using throw new Error('Datastore is corrupted') it's easier to trace my way back to what's happened.
When I plan to catch the exception I use throw 'problem'
Edit - on re-reading this I think the next part needs some caution. It's generally a good idea to be very specific about which error you choose to catch otherwise you can end up catching things that you really wanted to bubble all the way up. In general it's probably better to create a specific error type and catch that specific error (or message string). This allows errors you didn't anticipate to bubble up to the surface."
If the error is an expected error that I plan to catch and handle then I'm not going to get much use out of the stack snapshot.
So, let's say I use an http service and it returns a 500 HTTP code. I may treat this as an error which I throw "responseCode=500" and then subsequently catch and handle.

React behavior
Apart from the rest of the answers, I would like to show one difference in React.
If I throw a new Error() and I am in development mode, I will get an error screen and a console log. If I throw a string literal, I will only see it in the console and possibly miss it, if I am not watching the console log.
Example
Throwing an error logs into the console and shows an error screen while in development mode (the screen won't be visible in production).
throw new Error("The application could not authenticate.");
Whereas the following code only logs into the console:
throw "The application could not authenticate.";

The Error class includes debugging information (as properties of its instances), such as the error's call stack. JS interpreters know how to serialise those properties into an informative error message string, and they can also be consumed by debugging software - such as browser dev tools - to construct a more informative GUI representation of the error. This is why it's generally more useful to throw an instance of the Error class rather than simply throwing, for example, a string describing the error, or a number representing an error code.
Using custom errors
It's particularly useful to make your own subclasses of Error, which allow you to uniquely identify different types of error with a descriptive name and machine-readable...
clues for debugging,
information for better user-facing error messages, or
information to help recover from the error.
Then, when you're handling errors, you can use the nice and clean instanceof operator to check what kind of error occurred. e.g.:
class ShoesTooBig extends Error {}
class DangerousWaterCurrent extends Error {
constructor(waterSpeed){
super(`These waters are moving at ${waterSpeed} metres per second - too fast to cross!`) // Provide a `message` argument to the Error() constructor
this.waterSpeed = waterSpeed // This passes some context about why/how the error occurred back to whichever function is going to catch & handle it
}
}
// ...later...
try {
swimAcrossRiver(footwear, river)
} catch (thrownValue) {
if (thrownValue instanceof DangerousWaterCurrent) {
constructDam(river, thrownValue.waterSpeed)
} else {
throw thrownValue // "Re-throw" the error back up the execution chain, for someone else to handle
}
}
new Error() vs Error()
There is a "convenient" shorthand way to make an instance of Error: by calling Error(message), instead of new Error(message), the way you'd make an instance of a normal class. This is a deliberate exception, inserted by the language designers, to the rule. There are similar shorthands for other in-language classes, like Number() and String(). They also let you call these classes with () as if they were functions, not classes. JS doesn't allow normal classes to do this, even though they're all actually functions under the syntactical sugar of "classes". Try in a REPL:
> class E extends Error {}
undefined
> Error(); 'a value'
"a value"
> E(); 'a value'
Uncaught TypeError: Class constructor E cannot be invoked without 'new'
at <anonymous>:2:1
Personally, I think this design decision was a mistake, as it adds more exceptions to the rules of JavaScript - which means more to learn for programmers, and more for language translators/interpreters to account for. Instead of C++/Java's new keyword, simply calling a class as if it were a function (as in Number("abc123")) should have the properties that the new keyword currently has: the class's constructor function should be executed, with this bound to the instance. The new keyword could then be discarded from the language. This is how Python's syntax works, and it's simpler, more readable, and more convenient.

This is quite old but hopefully, anyone searching this can still learn from this:
First and famous, in javascript, we have something called Primitive Wrapper; a primitive wrapper takes primitive data and represents it in an object format by simply using the "constructor pattern". Still yet, in primitive wrappers, you can decide to have your data returned as an object type or you can have it returned as its primitive type(in this situation, you are now given a go-ahead command for javascript to extract the primitive value and in this case, you don't use the new keyword).
In Summary:
throw "My error": this creates an Error object and returns the primitive data extracted from the constructor "this" object. And if you try checking the typeof in the catch block, it tells you its a primitive typeof "string"
throw new Error("My error"): this returns you an object where you can access the error value from the message property. What simply happens here is that the "new keyword" constructs a "this" object and assign "{name:"Error",message:"..."}" to it and returns it. And when you try to check the typeof from the catch block, you will see a typeof "object".
Note: in a situation where you explicitly pass in a custom object to the throw, it will behave as if you invoked the constructor using the new keyword and therefore, the catch block will return you the custom object and not the message property value. For example: throw {name:"RangeError",message:"range is out of scope",environment:"Happened in testing function"}.
In conclusion, use whatever suits you ones you know what you are doing. But for me if i don't need much data but rather just the error, then I go for Primitive returner.

throw something works with both object and strings.But it is less supported than the other method.throw new Error("") Will only work with strings and turns objects into useless [Object obj] in the catch block.

throw new Error() is good for throwing a specified error. But if you want to do custom error handling, it's better to use throw { example: 'error' } .
That is, if you want to know the specified error, use throw new Error("example string") , if you want to handle the error in custom, use throw.
function makeErrorResponse(err = {}, httpStatus, status, message, message) {
const error = new Error();
error.httpStatus = httpStatus;
error.status = status;
error.message = message;
error.err = err;
return error;
}
throw makeErrorResponse({}, 500, 500, 'server error');