comparison libinterp/parse-tree/pt-eval.cc @ 15244:c16357c4bdbb

attempt to display location of out of memory errors in interpreted code * pt-eval.cc (tree_evaluator::visit_statement): Handle std::bad_alloc exception here. * toplev.cc (main_loop): Simplify out-of-memory error message. * octave.cc (safe_source_file): Don't handle std::bad_alloc here. (execute_eval_option_code): Likewise. * ov-oncleanup.cc (octave_oncleanup::~octave_oncleanup): Likewise.
author John W. Eaton <jwe@octave.org>
date Tue, 28 Aug 2012 11:00:53 -0400
parents 2fc554ffbc28
children b055fc077224
comparison
equal deleted inserted replaced
15243:b241e69306a5 15244:c16357c4bdbb
754 } 754 }
755 } 755 }
756 catch (octave_execution_exception) 756 catch (octave_execution_exception)
757 { 757 {
758 gripe_library_execution_error (); 758 gripe_library_execution_error ();
759 }
760 catch (std::bad_alloc)
761 {
762 // FIXME -- We want to use error_with_id here so that we set
763 // the error state, give users control over this error
764 // message, and so that we set the error_state appropriately
765 // so we'll get stack trace info when appropriate. But
766 // error_with_id will require some memory allocations. Is
767 // there anything we can do to make those more likely to
768 // succeed?
769
770 error_with_id ("Octave:bad-alloc",
771 "out of memory or dimension too large for Octave's index type");
759 } 772 }
760 } 773 }
761 } 774 }
762 775
763 void 776 void
895 tree_statement_list *try_code = cmd.body (); 908 tree_statement_list *try_code = cmd.body ();
896 909
897 if (try_code) 910 if (try_code)
898 { 911 {
899 try_code->accept (*this); 912 try_code->accept (*this);
900 // FIXME: should std::bad_alloc be handled here?
901 } 913 }
902 914
903 if (error_state) 915 if (error_state)
904 { 916 {
905 error_state = 0; 917 error_state = 0;