www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Catching a hot potato

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
The other day i was re-reading the std.exception docs and stumbled
upon "It's ill-advised to catch anything, that is not Exception or
derived from it".
Can you show me examples when catching a Throwable is a good idea?
Also, i had some thoughts about catching AcessViolation exception in a
modular application to avoid my app crashing when a module crashes,
but i was told, that segfaults indicate a messed up memory and nothing
is guaranteed to work after a segfault.
My question is, is it true, that segfault means THE END, and if so,
what's the point in allowing to catch it?
Also, how do i prevent DLLs from crashing my process like that?
Oct 15 2011
parent reply Walter Bright <newshound1 digitalmars.com> writes:
On 10/15/2011 3:29 AM, Gor Gyolchanyan wrote:

 The other day i was re-reading the std.exception docs and stumbled
 upon "It's ill-advised to catch anything, that is not Exception or
 derived from it".
 Can you show me examples when catching a Throwable is a good idea?


When there's something your program needs to do in order to shut down 
gracefully (such as "engage the backup", or "try to save the user's 
data"), or if you want to generate a log message before stopping the 
program.

Catching it can also be used to shut down a failing subsystem and 
restart it.


 Also, i had some thoughts about catching AcessViolation exception in a
 modular application to avoid my app crashing when a module crashes,
 but i was told, that segfaults indicate a messed up memory and nothing
 is guaranteed to work after a segfault.


That's true, an access violation means you've got likely got memory 
corruption somewhere.


 My question is, is it true, that segfault means THE END, and if so,
 what's the point in allowing to catch it?


Debuggers need to catch all seg faults from the debuggee. OS services 
need to catch page faults in order to implement demand paged virtual 
memory, stack faults in order to extend the stack segment, etc.


 Also, how do i prevent DLLs from crashing my process like that?


You'll need to figure out how to run your DLL in a separate address 
space, like a debugger would.
Oct 15 2011
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Thanks! I never thought, you could give a DLL another address space.
I don't quite understand how it works yet, but i'll look into it.

On Sat, Oct 15, 2011 at 8:15 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 On 10/15/2011 3:29 AM, Gor Gyolchanyan wrote:

 The other day i was re-reading the std.exception docs and stumbled
 upon "It's ill-advised to catch anything, that is not Exception or
 derived from it".
 Can you show me examples when catching a Throwable is a good idea?


 When there's something your program needs to do in order to shut down
 gracefully (such as "engage the backup", or "try to save the user's data"),
 or if you want to generate a log message before stopping the program.

 Catching it can also be used to shut down a failing subsystem and restart
 it.


 Also, i had some thoughts about catching AcessViolation exception in a
 modular application to avoid my app crashing when a module crashes,
 but i was told, that segfaults indicate a messed up memory and nothing
 is guaranteed to work after a segfault.


 That's true, an access violation means you've got likely got memory
 corruption somewhere.


 My question is, is it true, that segfault means THE END, and if so,
 what's the point in allowing to catch it?


 Debuggers need to catch all seg faults from the debuggee. OS services need
 to catch page faults in order to implement demand paged virtual memory,
 stack faults in order to extend the stack segment, etc.


 Also, how do i prevent DLLs from crashing my process like that?


 You'll need to figure out how to run your DLL in a separate address space,
 like a debugger would.
Oct 15 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 15.10.2011 18:29, schrieb Gor Gyolchanyan:

 Thanks! I never thought, you could give a DLL another address space.
 I don't quite understand how it works yet, but i'll look into it.


I never heard of this either, but it sounds pretty interesting.
If you find information about it please post some links here :-)

(Is this a Windows DLL only thing or does it also work with Linux/Unix 
shared libraries?)

Cheers,
- Daniel


 On Sat, Oct 15, 2011 at 8:15 PM, Walter Bright
 <newshound1 digitalmars.com>  wrote:

 On 10/15/2011 3:29 AM, Gor Gyolchanyan wrote:

 The other day i was re-reading the std.exception docs and stumbled
 upon "It's ill-advised to catch anything, that is not Exception or
 derived from it".
 Can you show me examples when catching a Throwable is a good idea?


 When there's something your program needs to do in order to shut down
 gracefully (such as "engage the backup", or "try to save the user's data"),
 or if you want to generate a log message before stopping the program.

 Catching it can also be used to shut down a failing subsystem and restart
 it.


 Also, i had some thoughts about catching AcessViolation exception in a
 modular application to avoid my app crashing when a module crashes,
 but i was told, that segfaults indicate a messed up memory and nothing
 is guaranteed to work after a segfault.


 That's true, an access violation means you've got likely got memory
 corruption somewhere.


 My question is, is it true, that segfault means THE END, and if so,
 what's the point in allowing to catch it?


 Debuggers need to catch all seg faults from the debuggee. OS services need
 to catch page faults in order to implement demand paged virtual memory,
 stack faults in order to extend the stack segment, etc.


 Also, how do i prevent DLLs from crashing my process like that?


 You'll need to figure out how to run your DLL in a separate address space,
 like a debugger would.
Oct 15 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I think there are performance implications when loading DLL's in a
separate address space. You won't be able to just pass callbacks
between your DLL and your app if they're not in the same address
space.

I don't know of any app which uses a separate address space for its
plugins. Maybe it's more popular on Linux though?
Oct 15 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/15/2011 10:58 AM, Andrej Mitrovic wrote:

 I don't know of any app which uses a separate address space for its
 plugins.


Debuggers.
Oct 15 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/16/11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 10/15/2011 10:58 AM, Andrej Mitrovic wrote:

 I don't know of any app which uses a separate address space for its
 plugins.


 Debuggers.


I wouldn't say that loading an executable in a debugger makes it a
plugin, it doesn't extend the feature-set of the debugger itself.
Unless it's an actual debugger plugin, but those are usually loaded in
the same address space. Hot potatos! :p
Oct 16 2011
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 15 Oct 2011 19:29:32 +0300, Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com> wrote:


 Thanks! I never thought, you could give a DLL another address space.
 I don't quite understand how it works yet, but i'll look into it.


Running a DLL in a separate address space (if possible at all, I think the  
concept of DLLs contradicts this idea) would not be much different than  
running the DLL as a separate process. Communication could then occur  
through pipes, sockets, or shared memory + signals/events/mutexes.

You may have noticed that some web browsers (Chrome, and now Firefox) run  
3rd-party plugins in separate processes, for this purpose (stability) plus  
security (plugins are sandboxed).

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Oct 15 2011