As odd as it sounds, I need to trigger a crash for testing. I tried various forms of calling a declare that doesn’t exist, but that just gets logged to console instead.
Declare Function DoesNotExist Lib "Cocoa.framework" selector "doesNotExist" (Target As Ptr) As Integer
Var Result As Integer = DoesNotExist(Nil)
Any other ideas?
Just declare to a C function and call with null pointer where it’s not expected.
Or call with wrong parameters to corrupt stack.
Something about @Sam_Rowlands 's thing with a setting and crash on NSException? I can’t find the blog post. Did find this thread:
No luck so far. defaults write com.thezazstudios.myapp NSApplicationCrashOnExceptions -bool YES doesn’t seem to change anything with the given code. And I don’t know enough of the standard C library to write a valid call. Writing an invalid call causes the compiler to fail.
Try calling a function that an object doiesn’t respond to.
declare sub setFrame lib "AppKit" selector "setFrame:" ( NSWindowInstance as integer, frameRect as NSRect )
Dim r as NSRect
setFrame( me.truewindow.handle, r )
Or do something like releasing an object, while it is still in use.
Declare sub NSObjectRelease lib "Foundation" selector "release" ( NSObjectInstance as integer )
NSObjectRelease( me.handle )
I simply typed these in the forum, so there may be typos.
There’s also this If you ever need to crash – Writings from the sticks
I did too, this is what I did:
dim m as memoryBlock
dim n as integer
dim s as string
s = "abc"
n = String2Memblock(s, m, 0, 10000000) // write to non-existent ptr: CRASH
String2Memblock is this:
static long String2Memblock (REALstring sourceStr, REALmemoryBlock destMemBlock, long destOffset, long nBytes)
{ unsigned char *sourcePtr, *destMemBlockPtr;
long j;
sourcePtr = (unsigned char *) (sourceStr->CString());
destMemBlockPtr = (unsigned char *) REALMemoryBlockGetPtr(destMemBlock);
destMemBlockPtr+=destOffset;
memcpy(destMemBlockPtr, sourcePtr, nBytes);
return nBytes;
}
I can send you my plugin that contains this call if you like.
I could just code a few lines for you. That seems to work well for me. 
The MBS plugin - of course - has methods for crashing. I don’t remember the function names.
How about just doing something like this…?
// example of how to deliberately throw an error
#Pragma BreakOnExceptions False
Var e As New RuntimeException
e.ErrorNumber = 1000
e.Message = "A custom exception was thrown!"
Raise e
#Pragma BreakOnExceptions Default
I think Norman’s technique is the most promising. I haven’t tried any of them since my last post though, so thank you for all the leads.
That’s an exception, not a crash.
Did a mod choose a solution for me? What the heck? I definitely didn’t pick one. I was coming back to select a solution now because I just got around to test, and I find a solution has already been selected? That’s not cool.
I don’t think any of us would have done it on purpose…there’s just no reason to. I’ve unmarked the solution.
Well it was the right solution, but… I didn’t do it. So I set it back.
I’ve seen such bad behavior too, but I chose to accept it for such case, as a courtesy.
Can someone explain what Norman’s code is doing and why it causes a crash? Also, is Norman’s crash something that you can catch and recover from? I’m not getting what this is all about.
A nil pointer access will always crash.
That is normal, can’t really be caught in Xojo.
Except maybe our SignalHandlerMBS class, but that wouldn’t prevent the app exiting.
Wes, you have the explanation here: Why does this crash ? – Writings from the sticks
@Julen_I Thanks for the link. It makes sense to me now.