# RoR: Best way to handle fatal errors

**URL:** <https://www.ruby-forum.com/t/ror-best-way-to-handle-fatal-errors/181564>\
**Category:** Rails\
**Created:** [January 13, 2010, 9:18pm UTC](https://www.ruby-forum.com/t/ror-best-way-to-handle-fatal-errors/181564 "2010-01-13T21:18:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ralphshnelvar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e19adc/32.png) [@ralphshnelvar](https://www.ruby-forum.com/u/ralphshnelvar)\
**Post date:** [January 13, 2010, 9:18pm UTC](https://www.ruby-forum.com/t/ror-best-way-to-handle-fatal-errors/181564/1 "2010-01-13T21:18:51Z")

</div>

Assume that a fatal error has occurred during (a) initialization; or (b)  
at “run time”.

(a) Let’s say a critical file or exe has gone missing during  
initialization. What is the best way to report this fact?

(b) Let’s say that a disk drive has filled up … or there is a similar  
problem that has not been caused by the user of one’s software. What’s  
the best way to inform the administrator and the user of this fact?

---

<div class="post-metadata">

**Author:** ![ralphshnelvar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e19adc/32.png) [@ralphshnelvar](https://www.ruby-forum.com/u/ralphshnelvar)\
**Post date:** [January 13, 2010, 10:24pm UTC](https://www.ruby-forum.com/t/ror-best-way-to-handle-fatal-errors/181564/2 "2010-01-13T22:24:05Z")

</div>

Ralph S. wrote:

> Assume that a fatal error has occurred during (a) initialization; or (b)  
> at “run time”.
> 
> (a) Let’s say a critical file or exe has gone missing during  
> initialization. What is the best way to report this fact?
> 
> (b) Let’s say that a disk drive has filled up … or there is a similar  
> problem that has not been caused by the user of one’s software. What’s  
> the best way to inform the administrator and the user of this fact?

Use ExceptionNotifier or similar. If the error is so severe that the  
Rails app itself can’t run, use a monitoring utility such as Nagios.

## Best,

Marnen Laibow-Koser  
[http://www.marnen.org](http://www.marnen.org)  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![ralphshnelvar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e19adc/32.png) [@ralphshnelvar](https://www.ruby-forum.com/u/ralphshnelvar)\
**Post date:** [January 13, 2010, 10:35pm UTC](https://www.ruby-forum.com/t/ror-best-way-to-handle-fatal-errors/181564/3 "2010-01-13T22:35:16Z")

</div>

You should lookup the differences between backend and frontend server  
components. Much of what you are describing will be handled throughout  
different areas of your server.

Example:

Your server runs on a 1gb mem slice and you decide to go down to say a  
256mb mem slice. The next day your server isn’t responding but you  
investigate and find out that your server encountered memory issues.

If you were using say Phusion Passenger + Apache + Rails the rails logs  
would show nothing about the mem issue and crash. Passenger may show  
pipe issues but not provide a detailed response about the crash. When  
you check the apache logs you’ll find the mem issue and the crash.

Basically, make sure you account for many issues across multiple  
components which include rails, your frontend, and your backend server  
components. Marnen suggested some ideas you can do above for one  
portion. Don’t forget about the rest.

I would also visit and check out the screencasts for Scaling Rails.

> **[Scaling Rails Screencasts | Programming Zen](https://programmingzen.com/scaling-rails-screencasts/)**
>
> Within the Rails community, New Relic is a company that doesn’t need any introductions. They are synonymous with performance and reliability, thanks to their RPM product for monitoring, detecting, and fixing Rails application performance problems in...