what is good practice dealing with exceptions?

65 views
Skip to first unread message

Angelo Chen

unread,
Jul 17, 2012, 12:46:48 AM7/17/12
to Express
Hi,

In Java web apps, if an exception happens, only that user experience
it, other does not, thanks to its multi thread nature, and yet, the
program will never terminate, but simply goes back, allow you to
refresh or do something else.

In node/express, like following code:

exports.query_card = (req, res) ->
dao.get_card req.params.key, (err, card) ->
res.json({ status:'OK', flag: card.flag});

if the card is null, it will display this then program terminates:

node.js:201
throw e; // process.nextTick error, or 'error' event on first
tick
^
TypeError: Cannot read property 'closed' of null

run it under NODE_ENV=production, same result,

I know i need to check if it's null first before using it, but is
there some way to keep it running without terminating? using Forever/
Monit is one option, however it's different, it restarts the app, not
keeping the app running after exception, ideas?

Thanks,

Angelo



Scott

unread,
Jul 17, 2012, 1:38:49 AM7/17/12
to expre...@googlegroups.com
One thing I did that helped a lot is add this to app.js (in production
I have it send me an email notice):

process.addListener("uncaughtException", function (err) {
console.log("Uncaught exception: " + err);
console.trace();
});

Scott
> --
> You received this message because you are subscribed to the Google Groups "Express" group.
> To post to this group, send email to expre...@googlegroups.com.
> To unsubscribe from this group, send email to express-js+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/express-js?hl=en.
>

Angelo Chen

unread,
Jul 17, 2012, 2:36:24 AM7/17/12
to Express
Hi Scott,

Thanks for sharing, I added that and exception got caught, then it
just stop there until I press Ctrl C to terminate the app,

process.addListener "uncaughtException", (err) ->
console.log("Uncaught exception: " + err)

i think that's a good place to email me the problem, but after that?

Thomas White

unread,
Jul 17, 2012, 4:44:00 AM7/17/12
to expre...@googlegroups.com
Angelo,

I am not sure what is the context for you question: what is the use case and the are the actions you would like to take when an error occurs?

If you are asking "I just want to write a very light code without any data sanitizing, without checking the result of operation that may cause an error and exception and without taking care to recover from an error" then using a global event listener for errors is fine, especially when we write a quick and dirty throwaway code. 

On other hand implementing a generic data sanitizer is relatively simple and having an error handler that will allow you to recover from a specific error in a specific context and take appropriate actions according to the business logic, data flow and user experience makes more sense to me and will have much more value in a long run.

Another approach will be to create a global context object and update it when you go to the next step of your logic. This will allow the global error handler can take into account the state when the error toke place, and react accordingly.

I hope this helps.

Thomas











Thomas

------

Angelo Chen

unread,
Jul 18, 2012, 12:03:06 AM7/18/12
to Express
after some research, basically when uncaughtException occurs, the safe
approach is restart, adding that listener helps troubleshooting,
thanks.

On Jul 17, 1:38 pm, Scott <sheb...@gmail.com> wrote:
Reply all
Reply to author
Forward
0 new messages